Bug#1071826: bookworm-pu: package libreoffice/4:7.4.7-1+deb12u3
Package: release.debian.org
Severity: normal
Tags: bookworm
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: libreoff...@packages.debian.org, k...@packages.debian.org
Control: affects -1 + src:libreoffice
Hi,
I'd like to fix 2 libreoffice bugs in stable. Most important is
the SMB fix (which - for kf5 - also needs a kio stable update, but those
can be done in parallel or kio later as there's no updated
(build)-dependency needed. Merely I added a Recommends: for
documentation purposes.
[ Reason ]
a) #1059158
If using python3-uno, loadComponentFromURL apparently needs the
internal libforuilo.so ("formula ui") library to actually open it
since it tried to open that one.
Unfortunately this file if left out in the -nogui packages because it
is*ui.so. (In 32bit packages that is; in 64bit LO due to
--enable-mergelibs this is already in a bigger library called
libmergedlo.so)
b) 1069835
We shouldn't leave people having documents on SMB shares loose their
files :-)
[ Impact ]
a) opening calc files via python3-uno remaining broken
b) possible file loss for files on SMB shares
[ Tests ]
No test coverage. But a) is pretty straightforward abd b) was confirmed
that it
fixes it by the submitter.
[ Risks ]
a) would be better fixed by upstream not requiring that but the bug I
filed upstream (https://bugs.documentfoundation.org/show_bug.cgi?id=158795)
didn't really get any serious attention.
b) more SMB surprises can be possible, though I have not seen any since
this is in unstable since 24.2.2 is there.
(And that exact patch caused a 32bit FTBFS which I backported the fix of
which went into 24.2.2~rc1-2 packages and is upstream since 24.2.2 rc2
anyways, too.)
[ Checklist ]
[x] *all* changes are documented in the d/changelog
[x] I reviewed all changes and I approve them
[x] attach debdiff against the package in (old)stable
[x] the issue is verified as fixed in unstable
[ Changes ]
a) see above. It it just excluded from the find which removes *.ui.so.
b) patches from upstream applied verbatim (from 24.2.2)
[ Other info ]
kio needs one update, too for complete fix of 1069835 in
libreoffice-kf5. I see
https://salsa.debian.org/qt-kde-team/kde/kio/-/commi
t/082a2b7e9208a9d0a552049aafd898960fc15998
(debian/patches/fix_cifs_file_locks.patch).
According to
https://salsa.debian.org/qt-kde-team/kde/kio/-/commit/9db715803c0c87298dbf70644b98a95bb984322c
this was already supposed to be "released to bookworm" but I don't see a
release.debian.org bug nor the package in p-u either.
Debdiff attached.
Regards,
Renediff -Nru libreoffice-7.4.7/debian/changelog libreoffice-7.4.7/debian/changelog
--- libreoffice-7.4.7/debian/changelog 2024-04-01 11:05:27.0 +0200
+++ libreoffice-7.4.7/debian/changelog 2024-05-24 21:06:45.0 +0200
@@ -1,3 +1,18 @@
+libreoffice (4:7.4.7-1+deb12u3) bookworm; urgency=medium
+
+ * debian/patches/Fix-backup-copy-creation-for-files-on-mounted-samba-shares.diff:
+as name says, from 24.2.2+ (closes: #1069835)
+ * debian/patches/fix-32bit-build.diff: as name says; fix 32bit build with
+above
+
+ * debian/rules:
+- don't remove libforuilo.so in -core-nogui. (closes: #1059158)
+ It's subsumed in libmerged on 64bit archs anyway which we definitely
+ need to keep anyway (similar as libuuilo.so).
+- recommend kio >> 5.103.0-1 in -kf5
+
+ -- Rene Engelhard Fri, 24 May 2024 21:06:45 +0200
+
libreoffice (4:7.4.7-1+deb12u2) bookworm-security; urgency=high
* debian/patches/add-notify-for-script-use.diff: add fix for
diff -Nru libreoffice-7.4.7/debian/control libreoffice-7.4.7/debian/control
--- libreoffice-7.4.7/debian/control 2024-04-01 11:05:27.0 +0200
+++ libreoffice-7.4.7/debian/control 2024-05-22 18:16:51.0 +0200
@@ -5028,7 +5028,7 @@
${kf5-qt5-depends},
${misc:Depends},
${shlibs:Depends}
-Recommends: ${plasma-iconset-dep}
+Recommends: kio (>> 5.103.0-1), ${plasma-iconset-dep}
Replaces: libreoffice-kde (<< 1:6.1.0~alpha1-1)
Section: kde
Enhances: libreoffice
diff -Nru libreoffice-7.4.7/debian/patches/fix-32bit-build.diff libreoffice-7.4.7/debian/patches/fix-32bit-build.diff
--- libreoffice-7.4.7/debian/patches/fix-32bit-build.diff 1970-01-01 01:00:00.0 +0100
+++ libreoffice-7.4.7/debian/patches/fix-32bit-build.diff 2024-05-22 09:46:59.0 +0200
@@ -0,0 +1,54 @@
+From 0f5dfaebd61b9cabbe9762865563c2296ebb0112 Mon Sep 17 00:00:00 2001
+From: Stephan Bergmann
+Date: Fri, 8 Mar 2024 08:38:44 +0100
+Subject: [PATCH] Blind fix for Linux 32-bit builds
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+...which, according to
+<https://lists.freedesktop.org/archives/libreoffice/2024-March/091666.html> "32
+bit build failure (smb, narrowing)", started to fail with
+
+> /<>/sal/osl/unx/file.cxx: In function ‘void osl_file_adjustLockFla
Re: Bug#1068609: libreoffice: FTBFS on arrmhf: testContentGnumeric assertion failed,- Expression: xServiceInfo->supportsService("com.sun.star.sheet.SpreadsheetDocument")
Version: 4:24.2.2-3 Hi, Am 07.04.24 um 23:13 schrieb Rene Engelhard: Filing a bug for reference. This is fixed in 4:24.2.2-3, will mark it as such when I get the bug number. As said. Regards, Rene
libreoffice: FTBFS on arrmhf: testContentGnumeric assertion failed,- Expression: xServiceInfo->supportsService("com.sun.star.sheet.SpreadsheetDocument")
Source: libreoffice Version: 4:24.2.0-1 Severity: serious Tags: trixie ftbfs Hi, Am 30.03.24 um 12:56 schrieb Rene Engelhard: Am 30.03.24 um 08:49 schrieb Rene Engelhard: That would mean a bin-NMU of liborcus would work and then a rebuild of libreoffice (gb, but I need a new upload anyway) So we probably missed a rename? (Or more for stuff silently using time-date?) boost1.83 (iostream)? liborcus? Both? I prepared a time_t rename of liborcus. Can upload it (to NEW...) any time. A bin-NMU would also work, except for a needed runtime dependency, then again it's "only" the gnumeric filter...). I wouldn't mind a simple bin-NMU at least. That one got done on April 1 :) > Ran the full tests with it. Passed. (Unfortunately) that (expectedly) now causes the reverse issue in testing. Just verified in a local build. Fortunately the startup of LO works fine (tried on my machine here) so it's probably "just" gnumeric (and maybe other gnumeric-using filters) affected. Filing a bug for reference. This is fixed in 4:24.2.2-3, will mark it as such when I get the bug number. Regards, Rene
Re: liborcus / boost1.83 and time_t
Hi, Am 30.03.24 um 08:49 schrieb Rene Engelhard: That would mean a bin-NMU of liborcus would work and then a rebuild of libreoffice (gb, but I need a new upload anyway) So we probably missed a rename? (Or more for stuff silently using time-date?) boost1.83 (iostream)? liborcus? Both? I prepared a time_t rename of liborcus. Can upload it (to NEW...) any time. A bin-NMU would also work, except for a needed runtime dependency, then again it's "only" the gnumeric filter...). I wouldn't mind a simple bin-NMU at least. (I also uploaded libreoffice build-depending on liborcus-dev (>> 0.19.2-3+b1) on armhf) Ran the full tests with it. Passed. Though still I wonder whether something needs to be done for boost, too. (Probably a problem since it's header-only in parts) and whether I am the only one... Regards, Rene
liborcus / boost1.83 and time_t
Hi,
I got
qahelper.cxx:580:Assertion
Test name: testContentGnumeric::TestBody
assertion failed
- Expression:
xServiceInfo->supportsService("com.sun.star.sheet.SpreadsheetDocument")
Failures !!!
Run: 64 Failure total: 1 Failures: 1 Errors: 0
make[3]: *** [/<>/solenv/gbuild/CppunitTest.mk:130:
/<>/workdir/CppunitTest/sc_subsequent_filters_test.test]
Error 1
make[3]: Leaving directory '/<>'
make[2]: *** [Makefile:277: build] Error 2
make[2]: Leaving directory '/<>'
make[1]: *** [/<>/debian/rules:2501: check] Error 2
make[1]: Leaving directory '/<>'
make: *** [debian/rules:2389: debian/stampdir/build-arch] Error 2
on the libreoffice 4:24.2.2-1 build on the buildds after it is now
buildable again due to being held up by time_t.
The gnumeric filter mentioned here is consumed from liborcus.
liborcus hasn't been rebuilt yet since the boost1.83-default transition.
It also doesn't depend on libboost-chrono1.83 which is afaics the boost
library which was renamed for time_t. (just iostreams - and for whatever
reason also system on sparc64).
And iostreams doesn't depend on chrono...
boost though has been rebuilt for time_t. And liborcus does use
time-date parts of boost (which doesn't result in linkage)
Back before the transition started without anything actually rebuilt yet
I got a test failure in a test build with abi=+time64 unless I rebuilt
xmlsec1. Which is reflected in the build-depends.
Anyways, as this gnumeric filter is consumed from liborcus I thought
about this being a fallout of time_t and tried to rebuild liborcus.
Rebuilding liborcus and dpkg -i'ing it and then running the test makes
the test pass where it failed here before, too.
That would mean a bin-NMU of liborcus would work and then a rebuild of
libreoffice (gb, but I need a new upload anyway)
So we probably missed a rename? (Or more for stuff silently using
time-date?)
boost1.83 (iostream)? liborcus? Both?
Regards,
Rene
Re: Ability to further support 32bit architectures
Hi, Am 13.01.24 um 13:59 schrieb rhys: No. You are AGAIN assuming what I am talking about. Maybe because of how you write... I know the difference between a 32-bit processor and a 64-bit processor. Obviously you don't. Or at least are not aware about consequences. Since you still offer 32bit machines of which Debian has enough of. (64 bit kernel probably but it doesn't matter) where it does not matter at all. You ignore the stated fact in this thread that on a 32bit processor one process can't get more than 3GB or even less of RAM (regardless of what memory extension stuff exists). In https://lists.debian.org/debian-kernel/2024/01/msg00191.html (where the quoting is a problem, one doesn't know what is yours and what not) you ignored what YunQiang said in the post you replied to: https://lists.debian.org/debian-kernel/2024/01/msg00189.html Quoting again just for you: "[...] It is about some limitation of 32bit. 2 examples for it: 1. if we use 32bit value for time, it will overflow in 2038, then your time will be shown as 1900. https://en.wikipedia.org/wiki/Year_2038_problem 2. A single process (or maybe APP, not precisely), can only use UP to 4GiB RAM. In fact on most system the value is less than 4GiB: on intel32, it is 3GiB on mips32, it is 2GiB But currently, it is not enough, for example, when we build a big APP, it will need much more RAM. The RAM does install in your Rack, but you can NOT use it. https://en.wikipedia.org/wiki/3_GB_barrier " And THAT (2.) is the problem here for linking big applications/compile units. Not the lack of machines. And that is a limitation of *the architecture*. Putting more "32bit machines" on it do not change anything of that except that there were more machines which cannot build big stuff. Regards, Rene
Bug#1036884: 64-bit time_t: updated archive analysis, proposed transition plan with timeline
Hi,
Am 07.01.24 um 04:38 schrieb Steve Langasek:
The ordering here would be:
- dpkg will be uploaded to experimental with 64-bit time_t in the default
flags
- the source packages which need an ABI change
("source-packages"+"lfs-and-depends-time_t") and do not already have
versions in experimental, will have sourceful NMUs to experimental with
the new binary package names in order to clear binary NEW, in coordination
- once these packages have all cleared binary NEW, the new dpkg defaults
will be uploaded to unstable
And in the meanwhile in experimental it will be built with the old
time_t on other architectures.
Since the new dpkg won't be picked up.
Not in the experimental builders unstable+experimental chroots which
only install experimental packages when Build-Depends: need them.
(For an undefined time given how much the packages later in the chain
wait in NEW)
Especially on armhf which is affected. Or will you do the source NMUs on
armhf/i386? (For some packages where some features are disabled on 32bit
this is probably not a good idea)
Regards,
Rene
Bug#1036884: 64-bit time_t: updated archive analysis, proposed transition plan with timeline
Hi,
Am 07.01.24 um 02:01 schrieb Steve Langasek:
If you say you are going to fix eventual breakage (and not ignoring
the test
results!) and if that means fixing asm on all affected archs, then it's OK
:)
Well, yes; though I hope we would see some help from e.g. arm porters if
there were actually breakage of this nature.
Hope doesn't help when it got to the actual problem and this doesn't happen.
Alternatively, maybe it would
be better to stop shipping libreoffice on 32-bit archs, in that case? I'm
I'd like to avoid this. Getting rid of i386 is fine, noone needs it,
armhf is a bit different.
(rpis etc - even though they could run arm64, but..)
not sure how usable libreoffice is these days on such archs.
popcon.debian.org doesn't appear to have the granularity to tell us if there
actually *are* users; and with only 615 armhf popcon reports (vs 215,562 on
amd64) we don't exactly have a statistically significant sample there.
Only recently I got
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1059158. Maybe UI is
not used much, but I can imagine people using it in paperless-ngx or
other stuff.
I don't really want to bastardize those uses.
- the source packages which need an ABI change
("source-packages"+"lfs-and-depends-time_t" will have sourceful NMUs to
I get that you probably want NMUs for not needing to ping every maintainer,
but this is bad.
That e.g. would cause me to upload libreoffice 24.2 rc2 to sid immediately
when tagged end of next week to not have this caught in the transition. (see
also below for the comment about new upstream versions in experimental.)
What about the suggestion to not push changes to experimental for packages
that already have new versions in experimental, and do the binary package
renames in unstable instead, leaving the package in experimental alone?
If at all - *both*. At the same time.
Most of these packages that are staged in experimental are going to be there
because of library transitions...
And ignore those who use experimental as a testbed of major new
upstreams? Doesn't sound good.
experimental with the new binary package names in order to clear binary
NEW, in coordination
And what about skipped ones? When will those be tried?
What do you mean here by "skipped ones"?
https://adrien.dcln.fr/misc/armhf-time_t/2023-12-18/results_skipped.txt
(which incidentially contains libreoffice)
Ah! These are packages that have been omitted from the analysis because
they've been manually identified as packages that don't have C or
C++-compatible header files related to a shared library, and therefore even
if they do need updated for 64-bit time_t, they are not affected by CPPFLAGS
and are not part of this transition. (I am not 100% sure this is accurate
for ObjC; in any case ObjC headers are impossible to analyze using
abi-compliance-checker so if ObjC libraries are possibly affected, someone
would have to figure out what to do with them.)
I have no idea on how you indentified it In the libreoffice case that is
not true.
libreoffice-dev-(common) *does* contain C/C++ header files.
And most of them *do* correspond to the libuno* shared packages.
Just that they are not split per library because that wouldn't really
make sense since you need any of them anyway.
And I definitely see
e.g. /usr/include/libreoffice/osl/time.h (libuno-sal3)
No idea whether it actually will be broken by the change, but...
I'm not sure precisely why Adrien found it necessary/useful to add
libreoffice-dev to this exclude list,
Probably because he didn't look at the whole but just at the package
but I can confirm that it's
reasonable, as this particular package contains only a single header file
with #define's and no function prototypes; so in effect it has been manually
analyzed and determined to be unaffected.
But libreoffice-dev-common not (on which libreoffice-dev depends) which
contains all the arch-indep headers. Just libreoffice-dev contains one
header diferent between archs.
Regards,
Rene
Bug#1036884: 64-bit time_t: updated archive analysis, proposed transition plan with timeline
Hi, Am 06.01.24 um 06:51 schrieb Steve Langasek: - dpkg will be uploaded to experimental with 64-bit time_t in the default flags [...] What about the suggestion to not push changes to experimental for packages that already have new versions in experimental, and do the binary package renames in unstable instead, leaving the package in experimental alone? How does that play together with the needed dpkg only in experimental? You can't build stuff for unstable involving experimental packages (except manually with binary upload, which would block testing migration) Regards, Rene
Bug#1036884: 64-bit time_t: updated archive analysis, proposed transition plan with timeline
Hi Steve,
Am 06.01.24 um 06:51 schrieb Steve Langasek:
- dpkg will be uploaded to experimental with 64-bit time_t in the default
flags
I think at that point in time one should know what breaks and whatnot.
Archive rebuild?
(Probably in stages)
What kind of breakage are you looking to avoid here? As mentioned in other
build failures/test failures.
points in the thread, regressions as a result of this change should be rare
and easy to fix. I do not think it's a good use of time / CPU power to do
test rebuilds for this instead of just landing the transition.
Here especially LibreOffices bridge code worries me.
That one is tied to ABI and calling conventions. I don't see time_t
mentioned there but "just" in the public libraries (sal), but I am not
sure what making a type bigger will cause.
(And since already
- i386 needs gcc-12 to build since otherwise the test fails
- armhf (and other archs like ppc64el and s390x) need Java disabled[1]
- without any help from any porter to prevent this - I *do* want to
avoid breakage here.
If you say you are going to fix eventual breakage (and not ignoring the
test results!) and if that means fixing asm on all affected archs, then
it's OK :)
- the source packages which need an ABI change
("source-packages"+"lfs-and-depends-time_t" will have sourceful NMUs to
I get that you probably want NMUs for not needing to ping every maintainer,
but this is bad.
That e.g. would cause me to upload libreoffice 24.2 rc2 to sid immediately
when tagged end of next week to not have this caught in the transition. (see
also below for the comment about new upstream versions in experimental.)
What about the suggestion to not push changes to experimental for packages
that already have new versions in experimental, and do the binary package
renames in unstable instead, leaving the package in experimental alone?
If at all - *both*. At the same time.
But yes, that could work.
(In this specific case I an worrying that the transition will take some
time, and that I am stuck with 7.6.x instead of uploading 24.2 when it
is released.)
libreoffice libs only have one reverse-dep, zemberek-ooo; so the risk of
entanglement here is small anyway.
Except in poppler etc. transitions.. But yeah, nothing really uses the
C++ libs nowadays.
I think the above proposal, to skip packages already in experimental from
the set of uploads to experimental, would address your concern. It's not as
if there is going to be any time that it's ok to tell maintainers they can't
use experimental at all because we're doing this transition.
experimental with the new binary package names in order to clear binary
NEW, in coordination
And what about skipped ones? When will those be tried?
What do you mean here by "skipped ones"?
https://adrien.dcln.fr/misc/armhf-time_t/2023-12-18/results_skipped.txt
(which incidentially contains libreoffice)
Regards,
Rene
[1] Ubuntu just ignores the test failures. No, not an option.
Bug#1036884: 64-bit time_t: updated archive analysis, proposed transition plan with timeline
Hi,
Am 05.01.24 um 09:17 schrieb Steve Langasek:
- Packages that could not be analyzed for whatever reason are still
assumed to have an ABI that's sensitive to time_t and have to be included
in the transition. Happily, due to improvements in this run of the number
of packages that could successfully be analyzed, the number of libraries
in this category has dropped from 1541 to 929, of which 69 have no
reverse-dependencies at all. The final list of these header packages that
could not be analyzed is attached, in case anyone still wants to identify
that a library on this list whose ABI is not affected by time_t and should
therefore be excluded from the transition. Note, however, that no effort
has been made to filter out dev packages from this list that come from
source packages containing OTHER dev packages that are known to have ABI
breakage; for a number of the packages listed, further analysis would not
change the outcome. (e.g. qt5-qmake failed to be analyzed, but
qtbase-opensource-src also ships qtbase5-private-dev which shows time_t
ABI sensitivity.)
[...]
My strawman proposal is to give this thread 2 weeks from today for feedback
and further refinement, and also to further reduce the number of
false-positives included in the transition. Then, starting on Jan 18:
- dpkg will be uploaded to experimental with 64-bit time_t in the default
flags
I think at that point in time one should know what breaks and whatnot.
Archive rebuild?
(Probably in stages)
- the source packages which need an ABI change
("source-packages"+"lfs-and-depends-time_t" will have sourceful NMUs to
I get that you probably want NMUs for not needing to ping every
maintainer, but this is bad.
That e.g. would cause me to upload libreoffice 24.2 rc2 to sid
immediately when tagged end of next week to not have this caught in the
transition. (see also below for the comment about new upstream versions
in experimental.)
experimental with the new binary package names in order to clear binary
NEW, in coordination
And what about skipped ones? When will those be tried?
Those also will need clear NEW if needed.
(And they might even FTBFS because the ABI did change and ABI-assuming
test break? Though I don't assume so for time_t, but if time is passed
around... I don't assume so, but...
At least that would be the case for libreoffice (and
libreoffice-dev-common is in the affected set, which means some stuff
relies on it...))
(Maybe even needing asm fixes)
- once these packages have all cleared binary NEW, the new dpkg defaults
will be uploaded to unstable
- the sourceful NMUs of the libraries will be reuploaded to unstable
(without binaries, so that they can be promoted to testing without
additional uploads).
Please let me know of any problems with this plan.
Also a problem is that experimental also might already contain totally
unrelated updates like new upstream versions...
Regards,
Rene
Bug#1059535: transition: abseil
Hi, Am 27.12.23 um 19:15 schrieb Benjamin Barenblat: Although doing a transition now will break some packages in sid, I believe waiting is likely to cause more issues. Upstreams (LibreOffice in particular) are starting to use features from the new version of Abseil, Actually it's not LibreOffice but LibreOffice indirectly via pdfium (which makes chromium also be affected if it did build without using the embedded copy of abseil). That said libreoffice builds (both sids and experimentals version). Tested on amd64 only, but Regards, Rene
Bug#1036904: bookworm-pu: package libreoffice/4:7.4.7-1
Hi again, Am 17.07.23 um 19:35 schrieb Rene Engelhard: Hi, Am 17.07.23 um 19:24 schrieb Jonathan Wiltshire: Hi, With the FTBFS of mipsel/mip64el in sid we need to make a choice before the weekend: - defer libreoffice update until 12.2, probably some time in the Autumn - propogate 4:7.4.7-1 to sid on those architectures, and testing on all architectures, if it passes installability tests there Which would you prefer? The latter. Given no answer on - mips for anything the last months I tend to just file a RM bug for sid for mipsel anyway as that one is completely broken and is probably even since a few releases. Filed as #1041340 Probably should do for mips64el, too That one not yet. Regards, Rene
Bug#1036904: bookworm-pu: package libreoffice/4:7.4.7-1
Hi, Am 17.07.23 um 19:24 schrieb Jonathan Wiltshire: Hi, With the FTBFS of mipsel/mip64el in sid we need to make a choice before the weekend: - defer libreoffice update until 12.2, probably some time in the Autumn - propogate 4:7.4.7-1 to sid on those architectures, and testing on all architectures, if it passes installability tests there Which would you prefer? The latter. Given no answer on - mips for anything the last months I tend to just file a RM bug for sid for mipsel anyway as that one is completely broken and is probably even since a few releases. Probably should do for mips64el, too Regards, Rene
Bug#1036904: bookworm-pu: package libreoffice/4:7.4.7-1
Hi, Am 12.07.23 um 23:01 schrieb Jonathan Wiltshire: Control: tag -1 confirmed [...] The version is fine. It may or may not make it into 12.1 depending on build times; we'll do our best. Uploaded, thanks. Regards, Rene
Bug#1028132: now ready
Hi, Am 27.06.23 um 00:15 schrieb Sebastian Ramacher: On 2023-06-18 13:57:01 +0200, Rene Engelhard wrote: Hi, hunspell-dict-ko was fixed/worked around the issue (0.7.94-1) so we can do this now. As said it's a no-op for anything except r-cran-hunspell which also is prepared in experimental together with hunspell itself. I might add a libhunspell-private-dev package later when I figured out how to best prevent this by adding a strict dependency there instead of hardcoding it... But even without that it's better to not have a copy of private headers in r-cran-hunspell. Can I upload to unstable? Please go ahead Uploaded, thanks. Andreas, you can upload r-cran-hunspell. Regards, Rene
Bug#1028132: now ready
Hi, hunspell-dict-ko was fixed/worked around the issue (0.7.94-1) so we can do this now. As said it's a no-op for anything except r-cran-hunspell which also is prepared in experimental together with hunspell itself. I might add a libhunspell-private-dev package later when I figured out how to best prevent this by adding a strict dependency there instead of hardcoding it... But even without that it's better to not have a copy of private headers in r-cran-hunspell. Can I upload to unstable? Regards, Rene
Bug#1036904: bookworm-pu: package libreoffice/4:7.4.7-1
Package: release.debian.org Severity: normal Tags: bookworm User: release.debian@packages.debian.org Usertags: pu X-Debbugs-Cc: libreoff...@packages.debian.org Control: affects -1 + src:libreoffice Hi, [ Reason ] Update to "current" version. (Latest version of stable branch) Same reasoning as of #1035056. This updates LibreOffice to the last version in the (dead, EOL is June 12) 7.4.x line[1] to fix a sh*load of bugs. List of bugs fixed: See [2] Quoting from #1035056: "there have been *hundreds* of bugs fixed since. Cherry-picking fixes for the most prominent crashes just isn’t practical considering especially how many bugs were fixed" Same reasoing here. [ Impact ] Unfixed bugs. [ Tests ] LibreOffice has a testsuite. [ Risks ] New upstream versions always have risk in contrast to what "x s" wants to claim in #1035056. It's the last release of a stable bugfix series, though. [ Checklist ] [x] *all* changes are documented in the d/changelog [x] I reviewed all changes and I approve them [x] attach debdiff against the package in (old)stable [ ] the issue is verified as fixed in unstable (not verified to be fixed in unstable yet since we are still in the freeze and I am not allowed to upload to sid) The 7.4.7 upstream release will (as of plans right now) never make trixie or even unstable at all since it's dead by then; will directly jump to 7.5.4-1. (Unless something last-minute happens) [ Changes ] 1. upstream update 7.4.5 -> 7.4.7. The two patches removed are security fixes which were already in 7.4.6 and 7.4.7 and now of course removed. No need to mention that in the changelog, it's implied by "New upstream release" that patches upstream are dropped. 2. the libreoffice-sdbc-postgresql has a Dependency on -core, not (as the other database drivers) -core-nogui | -core) so can't be installed with -nogui. But that one could come handy for mail merges or so if your data source is a pgsql. Didn't do it because of the freeze. 3. Even when running under nogui LO wants an .ui file at a --convert-to call. The fix (see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1028290) is just to exclude that from rm so it works. And actually also would make https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1024840 fixable. Although that admittedly is quote moot for stable since that won't affect it because 1024840 is no stable material anyway. But it might make sense to include nevertheless for people using --convert-to on ppt(x) in other means although most of them would use -impress and not -impress-nogui I guess ;) [ Other info ] I can back out the fix for 3. The other two are simply not discussable given #1035056. The whole diff is 1784 files changed, 52460 insertions(+), 52070 deletions(-) but the sole upstream update is 1776 files changed, 52442 insertions(+), 50892 deletions(-) of which ~1400 is just the translations, just the "core" is 388 files changed, 8359 insertions(+), 4481 deletions(-) The whole diff is 17M, so I am not attaching it here. It is at https://people.debian.org/~rene/libreoffice/7.4/7.4.7.debdiff I know this is completely bending the rules, but so is #1035056, too If you wish I can make this also -0deb12u1, but as there will be no 7.4.7-1 probably thia is not exactly needed. Regards, Rene [1] https://wiki.documentfoundation.org/ReleasePlan/7.4 [2] https://wiki.documentfoundation.org/Releases/7.4.6/RC1#List_of_fixed_bugs https://wiki.documentfoundation.org/Releases/7.4.6/RC2#List_of_fixed_bugs https://wiki.documentfoundation.org/Releases/7.4.7/RC1#List_of_fixed_bugs https://wiki.documentfoundation.org/Releases/7.4.7/RC2#List_of_fixed_bugs
Bug#1035056: Disappointed
Hi, an (in some way) outstanders point of view for this discussion. Am 16.05.23 um 09:37 schrieb x s: It’s really disappointing that the only reason for blocking Plasma 5.27.5 and Frameworks 5.104 is that there’s “too many packages”. It's disappointing that KDE people like this do not care at all about established rules and just start lobbying people because of their usually clueless userbase I observe on mailing list... KDE upstream has stopped feature development for Plasma 5.x and Frameworks 5.x with the releases of Plasma 5.27.0 and Frameworks 5.100, because the focus has completely switched to developing Plasma 6.0 and Frameworks 6.0 [1] [this link also explains the Fibonacci release cycle that you asked about]. Which is basically the same for many packages. I am njust going to talk about another prominent free software for desktops: LibreOffice (which I "normally" don't even use but maintain) That means Plasma 5.27.x and Frameworks 5.1xx are strictly only bug fix releases, they contain absolutely no new features and no major regressions have been reported in the newer versions. Just check the changelogs for every Plasma release since 5.27.2 and every Frameworks release since 5.103 (the versions Testing is stuck on), there have been *hundreds* of bugs fixed since. Cherry-picking fixes for the most prominent crashes just isn’t practical considering especially how many bugs were fixed in Plasma 5.27.3 alone. Same for LibreOffice for example. With the difference that the 7.4.x branch is dead basically now (https://wiki.documentfoundation.org/ReleasePlan/7.4) but also has "Only important bug fixes, and l10n improvements". Also quite a sh*load of bugfixes. See [2] I could have uploaded 7.4.7 two weeks ago, which would have even saved a last minute upload to fix two security issues because they were fixed upstream in that version Still I followed the freze and didn't upload 7.4.6 and 7.4.7. So should KDE and so should anyone. I’d like to remind you that GNOME 43.4 was allowed to migrate recently; why does GNOME get special treatment and KDE has to stay stuck on an older, buggier version? Debian KDE users would strongly appreciate you changing your stance and allowing the best versions to be included on release. I could say "Why does KDE get special treatment and LibreOffice has to stay stuck on an older, buggier version? Debian LibreOffice users would strongly appreciate you changing your stance and allowing the best versions to be included on release." See the problem? (actually I complained about that double morable and on doing this in effect in a secret cabal meeting yesterday on IRC) > If you still are not convinced on allowing these to be unblocked, would you at least consider allowing them to migrate for the Debian 12.1 point release? Again, I’d like to remind you that these are long-term support releases, they strictly fix bugs and contain no new features. There are absolutely no downsides to allowing them to migrate so they can be in Debian 12. I definitely have learned from this and will refer to this bug next freeze and get the latest LibreOffice in. (And try to get it updated in 12.1). There's no reason to deny that given this (imminent) approval of 50 source packages compared to one. All the other parameters are the same. Regards, Rene [1] https://wiki.documentfoundation.org/ReleasePlan/7.4 [2] https://wiki.documentfoundation.org/Releases/7.4.6/RC1#List_of_fixed_bugs https://wiki.documentfoundation.org/Releases/7.4.6/RC2#List_of_fixed_bugs https://wiki.documentfoundation.org/Releases/7.4.7/RC1#List_of_fixed_bugs https://wiki.documentfoundation.org/Releases/7.4.7/RC2#List_of_fixed_bugs
Bug#1036766: unblock: libreoffice/4:7.4.5-3
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: libreoff...@packages.debian.org, t...@security.debian.org
Control: affects -1 + src:libreoffice
Please unblock package libreoffice
[ Reason ]
1. Main reason is CVE-2023-2255 and CVE-2023-0950.
2. I had two changelog commits in my tree.
One is just documentation () and the other one fixes a simple
spelling error which lintian loudly complains about.
(cf.
https://udd.debian.org/lintian/?email1libreoffice==html_error=on_warning=on_tag=spelling-error-in-changelog#all)
That should be a no-brainer.
3. My tree also included the commit to make ulimit -c calls not fatal.
Since the bookworm update on ci this fails in lxc. There was a config
change (to be) deployed to prevent that but either it didn't happen
or was reverted. It still fails.
So we probably should include it, experimental has it for ages
already.
[ Impact ]
for 1. vulnerable LibreOffice
While we could do this via bookworm-security probably I think we can avoid
this since we do have
enough time..
for 3. autopkgtests still failing on ci.d.n inside lxc
[ Tests ]
Not sure whether the automatic tests cover this part.
It obviously builds ;)
[ Risks ]
The diff is big but the patch is taken verbatim from upstream 7.5
branch with just minor adaptions which are not risky (CVE-2023-2255)
and upstream 7.4.6 (CVE-2023-0950)
The ulimit -c changes are already in experimental.
The changelog fix/the addition do not have any risk at all (and it is
also already in experimental)
[ Checklist ]
[x] all changes are documented in the d/changelog
[x] I reviewed all changes and I approve them
[x] attach debdiff against the package in testing
unblock libreoffice/4:7.4.5-3
age-days 2 libreoffice/4:7.4.5-3
diff -Nru libreoffice-7.4.5/debian/changelog libreoffice-7.4.5/debian/changelog
--- libreoffice-7.4.5/debian/changelog 2023-02-05 18:40:59.0 +0100
+++ libreoffice-7.4.5/debian/changelog 2023-05-22 18:00:45.0 +0200
@@ -1,3 +1,17 @@
+libreoffice (4:7.4.5-3) unstable; urgency=high
+
+ * debian/patches/sc-stack-parameter-count.diff: fix CVE-2023-0950
+("Array Index UnderFlow in Calc Formula Parsing")
+ * debian/rules, debian/tests/*: don't fail if ulimit -c unlimited fails
+(like in ci.d.n infrastructure after the bookworm upgrade...)
+ * debian/patches/CVE-2023-2255.diff:
+fix CVE-2023-2555 ("Remote documents loaded without prompt via IFrame")
+ * debian/changelog:
+- mention CVE-2022-38745 in 1:7.3.1-1s changelog
+- fix typo in last upload (s/choosen/chosen/), thanks lintian
+
+ -- Rene Engelhard Mon, 22 May 2023 18:00:45 +0200
+
libreoffice (4:7.4.5-2) unstable; urgency=medium
* fontconfig-2.14.1-no-RGB-stripes-layout-for-sub-pixel-rendering.diff:
@@ -5,7 +19,7 @@
* debian/control.in:
- ... but build-conflict against affected fontconfig-configs (with
) instead since it now removes the offending config per default
- (buildd chroot...) if not choosen otherwise via debconf (see #103)
+ (buildd chroot...) if not chosen otherwise via debconf (see #103)
* debian/rules:
- Do not add documentation symlinks when not building documentation,
thanks Vagrant Cascadian (closes: #1030270)
@@ -502,6 +516,8 @@
libreoffice (1:7.3.1-1) unstable; urgency=medium
* LibreOffice 7.3.1 final release
+- fixes CVE-2022-38745: "Empty entry in Java class path risks arbitrary
+ code execution"
-- Rene Engelhard Thu, 03 Mar 2022 17:24:16 +
diff -Nru libreoffice-7.4.5/debian/patches/CVE-2023-2255.diff
libreoffice-7.4.5/debian/patches/CVE-2023-2255.diff
--- libreoffice-7.4.5/debian/patches/CVE-2023-2255.diff 1970-01-01
01:00:00.0 +0100
+++ libreoffice-7.4.5/debian/patches/CVE-2023-2255.diff 2023-05-20
12:21:27.0 +0200
@@ -0,0 +1,946 @@
+From 683e4de0de8dde7c5570c67cbd2bae17b6d7f0e0 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Caol=C3=A1n=20McNamara?=
+Date: Tue, 11 Apr 2023 10:13:37 +0100
+Subject: set Referer on loading IFrames
+
+so tools, options, security, options,
+"block any links from document not..."
+applies to their contents.
+
+Change-Id: I04839aea6b07a4a76ac147a85045939ccd9c3c79
+Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150225
+Tested-by: Jenkins
+Reviewed-by: Stephan Bergmann
+---
+ sfx2/source/doc/iframe.cxx | 13 ++---
+ 1 file changed, 10 insertions(+), 3 deletions(-)
+
+From 49a554471cddc3e52ae381f864e689fe4a8c6131 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Caol=C3=A1n=20McNamara?=
+Date: Thu, 13 Apr 2023 11:31:17 +0100
+Subject: put floating frames under managed links control
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+like we do for sections and ole objects that link to their content
+
+individual commits in trunk are:
+
+extract a OCommonEmbeddedObject::SetInpl
Bug#1033506: bullseye-pu: package libreoffice/1:7.0.4-4+deb11u6
Hi, Am 01.04.23 um 20:54 schrieb Adam D. Barratt: Control: tags -1 + confirmed On Sun, 2023-03-26 at 14:23 +0200, Rene Engelhard wrote: This fixes "CVE-2022-38745. Empty entry in Java class path risks arbitrary code execution" just disclosed by Apache OpenOffice. Please go ahead. Uploaded. Regards, Rene
Bug#1033506: bullseye-pu: package libreoffice/1:7.0.4-4+deb11u6
Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: libreoff...@packages.debian.org
Control: affects -1 + src:libreoffice
Hi,
This fixes "CVE-2022-38745. Empty entry in Java class path risks
arbitrary code execution" just disclosed by Apache OpenOffice.
libreoffice 7.0.4 in bullseye (and buster, but that is EOL) also is affected.
The security team thinks this doesn't warrant a DSA and should be done
here.
[ Checklist ]
[x] *all* changes are documented in the d/changelog
[x] I reviewed all changes and I approve them
[x] attach debdiff against the package in (old)stable
[x] the issue is verified as fixed in unstable
[ Changes ]
https://cgit.freedesktop.org/libreoffice/core/commit/?id=5e8f64e50f97d39e83a3358697be14db03566878
(which is fixed in 7.2.6 and 7.3.1) backported.
Debdiff:
diff -Nru libreoffice-7.0.4/debian/changelog libreoffice-7.0.4/debian/changelog
--- libreoffice-7.0.4/debian/changelog 2022-11-27 19:37:58.0 +0100
+++ libreoffice-7.0.4/debian/changelog 2023-03-25 14:04:55.0 +0100
@@ -1,3 +1,10 @@
+libreoffice (1:7.0.4-4+deb11u6) bullseye; urgency=medium
+
+ * debian/patches/avoid-empty-java.class.path.diff: apply upstream patch
+avoiding empty -Djava.class.path= (CVE-2022-38745)
+
+ -- Rene Engelhard Sat, 25 Mar 2023 14:04:55 +0100
+
libreoffice (1:7.0.4-4+deb11u5) bullseye; urgency=medium
* debian/patches/hrk-euro-default.diff: default to EUR for .hr
diff -Nru libreoffice-7.0.4/debian/patches/avoid-empty-java.class.path.diff
libreoffice-7.0.4/debian/patches/avoid-empty-java.class.path.diff
--- libreoffice-7.0.4/debian/patches/avoid-empty-java.class.path.diff
1970-01-01 01:00:00.0 +0100
+++ libreoffice-7.0.4/debian/patches/avoid-empty-java.class.path.diff
2023-03-25 14:04:55.0 +0100
@@ -0,0 +1,90 @@
+From 5e8f64e50f97d39e83a3358697be14db03566878 Mon Sep 17 00:00:00 2001
+From: Stephan Bergmann
+Date: Mon, 21 Feb 2022 11:55:21 +0100
+Subject: Avoid unnecessary empty -Djava.class.path=
+
+Change-Id: Idcfe7321077b60381c0273910b1faeb444ef1fd8
+Reviewed-on: https://gerrit.libreoffice.org/c/core/+/130242
+Tested-by: Jenkins
+Reviewed-by: Stephan Bergmann
+---
+ jvmfwk/plugins/sunmajor/pluginlib/sunjavaplugin.cxx | 16 +---
+ jvmfwk/source/framework.cxx | 8 ++--
+ jvmfwk/source/fwkbase.cxx | 3 +++
+ 3 files changed, 22 insertions(+), 5 deletions(-)
+
+diff --git a/jvmfwk/plugins/sunmajor/pluginlib/sunjavaplugin.cxx
b/jvmfwk/plugins/sunmajor/pluginlib/sunjavaplugin.cxx
+index 29de226211f1..e55b914edf13 100644
+--- a/jvmfwk/plugins/sunmajor/pluginlib/sunjavaplugin.cxx
b/jvmfwk/plugins/sunmajor/pluginlib/sunjavaplugin.cxx
+@@ -712,17 +712,22 @@ javaPluginError jfw_plugin_startJavaVirtualMachine(
+ // all versions below 1.5.1
+ options.emplace_back("abort", reinterpret_cast(abort_handler));
+ bool hasStackSize = false;
++#ifdef UNX
++// Until java 1.5 we need to put a plugin.jar or javaplugin.jar (<1.4.2)
++// in the class path in order to have applet support:
++OString sAddPath = getPluginJarPath(pInfo->sVendor,
pInfo->sLocation,pInfo->sVersion);
++#endif
+ for (int i = 0; i < cOptions; i++)
+ {
+ OString opt(arOptions[i].optionString);
+ #ifdef UNX
+-// Until java 1.5 we need to put a plugin.jar or javaplugin.jar
(<1.4.2)
+-// in the class path in order to have applet support:
+ if (opt.startsWith("-Djava.class.path="))
+ {
+-OString sAddPath = getPluginJarPath(pInfo->sVendor,
pInfo->sLocation,pInfo->sVersion);
+ if (!sAddPath.isEmpty())
++{
+ opt += OStringChar(SAL_PATHSEPARATOR) + sAddPath;
++sAddPath.clear();
++}
+ }
+ #endif
+ if (opt == "-Xint") {
+@@ -767,6 +772,11 @@ javaPluginError jfw_plugin_startJavaVirtualMachine(
+ }
+ #endif
+ }
++#ifdef UNX
++if (!sAddPath.isEmpty()) {
++options.emplace_back("-Djava.class.path=" + sAddPath, nullptr);
++}
++#endif
+
+ std::unique_ptr sarOptions(new
JavaVMOption[options.size()]);
+ for (std::vector::size_type i = 0; i != options.size(); ++i) {
+diff --git a/jvmfwk/source/framework.cxx b/jvmfwk/source/framework.cxx
+index 4163eea57b7c..8aa85082b838 100644
+--- a/jvmfwk/source/framework.cxx
b/jvmfwk/source/framework.cxx
+@@ -195,8 +195,12 @@ javaFrameworkError jfw_startVM(
+ //In direct mode the options are specified by bootstrap
variables
+ //of the form UNO_JAVA_JFW_PARAMETER_1 ..
UNO_JAVA_JFW_PARAMETER_n
+ vmParams = jfw::BootParams::getVMParameters();
+-sUserClassPath =
+-"-Djava.class.path=" + jfw::BootParams::getClasspath();
++
Bug#1028489: transition: boost1.81
Hi, Am 30.01.23 um 19:28 schrieb Anton Gladky: Just for the record. The full test rebuild has been done (thanks to Lucas!). Results and logs are here: http://qa-logs.debian.net/2023/01/15/ Just for the record: It definitely misses packages. Probably those which build-depend on boost but don't get a runtime dependency on anything boost'ish (because it uses the header parts) (And e.g. libreoffice is #1029104, not libreoffice 1:7.4.4~rc2-2 1:7.4.4~rc2-2 SAMEVER Failed Failed SAMERES 0 0 SAMETIME /bin/sh: 1: git: not found /bin/sh: 1: git: not found which is expected, we don't add the git version into the About box) Regards, Rene
Bug#1028132: transition: hunspell
[CCing hunspell-kos maintainer ] Hi, Am 08.01.23 um 19:24 schrieb Rene Engelhard: Hi, Am 07.01.23 um 16:45 schrieb Rene Engelhard: r-cran-hunspell included a copy of those internal headers and thus breaks when built against the newer ones. (And I assume will do so when built against the new ones against the old one.) See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1028124 for the gory details. I added Breaks: to hunspell 1.7.2+really1.7.2-5 and added a shlibs.local to my proposed solution to #1028124 Given the R team and thus this package is in https://wiki.debian.org/LowThresholdNmu I can upload hunspell and r-cran-hunspell together in one go (the latter as a NMU if required). Nevermind for now, even with the upstream fix for korean applied, some parts of hunspell-ko still fail... (see https://ci.debian.net/data/autopkgtest/unstable/amd64/h/hunspell-dict-ko/30142014/log.gz and https://github.com/hunspell/hunspell/issues/903, the original patch is applied in 1.7.2+really1.7.2-4) Will write again when this was sorted out somehow. Rgards, Rene
Bug#1028132: transition: hunspell
Hi, Am 07.01.23 um 16:45 schrieb Rene Engelhard: r-cran-hunspell included a copy of those internal headers and thus breaks when built against the newer ones. (And I assume will do so when built against the new ones against the old one.) See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1028124 for the gory details. I added Breaks: to hunspell 1.7.2+really1.7.2-5 and added a shlibs.local to my proposed solution to #1028124 Given the R team and thus this package is in https://wiki.debian.org/LowThresholdNmu I can upload hunspell and r-cran-hunspell together in one go (the latter as a NMU if required). Regards, Rene
Bug#1028132: transition: hunspell
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Blocks: -1 by 1028124 Hi, not a real transition but given that it involves Breaks: and a dependency bump with shlibs.local... hunspell 1.7.2 changed some *internal* headers. Unfortunately it broke hunspell-ko (fixed in 1.7.2+really1.7.2-4) and r-cran-hunspells test. r-cran-hunspell included a copy of those internal headers and thus breaks when built against the newer ones. (And I assume will do so when built against the new ones against the old one.) See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1028124 for the gory details. I added Breaks: to hunspell 1.7.2+really1.7.2-5 and added a shlibs.local to my proposed solution to #1028124 Changes in hunspell 1.7.2 according to upstream github announcement: --- snip --- Crash fixes, code clean-up in ~200 commits tdf#136306 don't accept/suggest typos as 3-or-more-word compound words Prepare optional spelling mode of LibreOffice to not accept/suggest not dictionary-based words as compound words (#517) Merge in weblate translations --- snip --- Regards, Rene
Bug#1027298: bullseye-pu: package libreoffice/1:7.0.4-4+deb11u5
Package: release.debian.org Severity: normal Tags: bullseye User: release.debian@packages.debian.org Usertags: pu Hi, follow up to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1016037. [ Reason ] As said, Croatia joins the Eurozone on Jan, 1 2023, i.e. in to days. That upload added support for Euro in Croatia. This upload switches the default. Something for stable-updates given the next point release is only mid-Feb? (Explain what the reason for the (old-)stable update is. I.e. what is the bug, when was it introduced, is this a regression with respect to the previous (old-)stable.) [ Impact ] Wrong currency default. Users might change it from the default to Euro, but... [ Checklist ] [x] *all* changes are documented in the d/changelog [x] I reviewed all changes and I approve them [x] attach debdiff against the package in (old)stable [x] the issue is verified as fixed in unstable [ Changes ] Upstream fix added 1:1. Full debdiff: diff -Nru libreoffice-7.0.4/debian/changelog libreoffice-7.0.4/debian/changelog --- libreoffice-7.0.4/debian/changelog 2022-09-06 18:54:37.0 +0200 +++ libreoffice-7.0.4/debian/changelog 2022-11-27 19:37:58.0 +0100 @@ -1,3 +1,9 @@ +libreoffice (1:7.0.4-4+deb11u5) bullseye; urgency=medium + + * debian/patches/hrk-euro-default.diff: default to EUR for .hr + + -- Rene Engelhard Sun, 27 Nov 2022 19:37:58 +0100 + libreoffice (1:7.0.4-4+deb11u4) bullseye-security; urgency=high * debian/patches/ZDI-CAN-17859.diff: fix ZDI-CAN-17859/CVE-2022-3140 diff -Nru libreoffice-7.0.4/debian/patches/hrk-euro-default.diff libreoffice-7.0.4/debian/patches/hrk-euro-default.diff --- libreoffice-7.0.4/debian/patches/hrk-euro-default.diff 1970-01-01 01:00:00.0 +0100 +++ libreoffice-7.0.4/debian/patches/hrk-euro-default.diff 2022-11-27 19:37:48.0 +0100 @@ -0,0 +1,42 @@ +From c698c75adc32e04521d182c409c3401370190efe Mon Sep 17 00:00:00 2001 +From: Eike Rathke +Date: Sun, 27 Nov 2022 17:11:49 +0100 +Subject: [PATCH] Resolves: tdf#150011 Switch default currency HRK Croatian + Kuna to EUR Euro + +HR will join Euro area on 2023-01-01. + +Change-Id: I3836804ff68419550091826ea2414bc0edd55a84 +Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143346 +Reviewed-by: Eike Rathke +Tested-by: Jenkins +(cherry picked from commit c58bc31ece80ccdfc88bd043787869c5e460dbd8) +--- + i18npool/source/localedata/data/hr_HR.xml | 5 ++--- + 1 file changed, 2 insertions(+), 3 deletions(-) + +diff --git a/i18npool/source/localedata/data/hr_HR.xml b/i18npool/source/localedata/data/hr_HR.xml +index 4de83e5535cd..1d29f1f2e0e6 100644 +--- a/i18npool/source/localedata/data/hr_HR.xml b/i18npool/source/localedata/data/hr_HR.xml +@@ -414,15 +414,14 @@ + + + +- ++ + HRK + kn + HRK + Hrvatska Kuna + 2 + +- +- ++ + EUR + € + EUR +-- +2.30.2 + diff -Nru libreoffice-7.0.4/debian/patches/series libreoffice-7.0.4/debian/patches/series --- libreoffice-7.0.4/debian/patches/series 2022-09-03 17:17:12.0 +0200 +++ libreoffice-7.0.4/debian/patches/series 2022-11-27 19:37:58.0 +0100 @@ -64,3 +64,4 @@ 0004-CVE-2022-2630-6-7-add-infobar-to-prompt-to-refresh-t.patch fix-e_book_client_connect_direct_sync-sig.diff ZDI-CAN-17859.diff +hrk-euro-default.diff [ Other info ] I just uploaded the sid fix (>= 7.4.4 rc1 have it for sid) and thus also could upload this now. Filing this bug for documentation purposes for stable. Regards, Rene
Bug#1016706: marked as done (transition: GNOME 43 mega libsoup3 transition)
Hi, What you just quoted was just the e-d-s part. There's s still https://release.debian.org/transitions/html/libsoup3.html Regards, Rene
Re: Bug#1019724: warning: stray \ before - causes autopkgtest failure
Hi, Am 15.09.22 um 15:50 schrieb Paul Gevers: On 15-09-2022 09:26, Paul Gevers wrote: I am trying to schedule autopkgtests in unstable on amd64 for all source packages that have one. And the first results are coming in. I'm not sure how to proceed though, see below. Lucas, are you in the position to do an archive rebuild to check for the grep warnings (see full history at [1]). When you submit bugs, can you please file them as important, as apparently upstream wants to turn these warnings into failures in the future, but in Debian Santiago is going to silence the warning soon, so FTBFS due to this isn't an RC problem on the short term. I wonder if this is going to be useful. The first couple of hits I inspected, the warning didn't occur in the autopkgtest itself, but during installation of required packages. Packages using ucf, yes. See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1019326 E.g. https://ci.debian.net/data/autopkgtest/unstable/amd64/l/lintian-brush/26114550/log.gz shows the warning while running update-perl-sax-parsers during installation libxml-sax-perl and https://ci.debian.net/data/autopkgtest/unstable/amd64/g/golang-github-lib-pq/26114898/log.gz shows the warning while installing postgresql-common A lot of tests use postgresql, so weeding that out isn't going to be trivial. Any ideas? (I'll of course file bugs against postqresql-common and whatever contains update-perl-sax-parsers, but I'll need more automation for the rest) Doesn't make sense imho, as neither has a bug and it's actually ucf in many cases doing the grep in question. Regards, Rene
Re: uncoordinated abseil transition ( was: Re: Accepted abseil 0~20220623.0-1 (source amd64) into unstable, unstable)
Hi, Am 29.08.22 um 03:47 schrieb Benjamin Barenblat: Thank you so much for doing all the work to figure out what packages I need to binNMU! I’ll get the ppc64el tests fixed and take care of the binNMUs ASAP. You probably can't, the release team can do that, though. Please let me know if you (or anybody else on the release team) would like me to coordinate Abseil transitions in the future. *You* have to do it. https://wiki.debian.org/Teams/ReleaseTeam/Transitions. You haven't followed anything of this. I suspect at some point Abseil dependencies are going to be common enough that transitions will need to be fully coordinated, but having never maintained a library this popular before, I’m not sure what that point is. I'd say you reached this point already. Regards, Rene
Re: uncoordinated abseil transition ( was: Re: Accepted abseil 0~20220623.0-1 (source amd64) into unstable, unstable)
Hi, (last mail for this topic for now, don't worry.) Am 28.08.22 um 21:19 schrieb Rene Engelhard: Quick testing with apt-get -b source (except of libreoffice, which I only did to after the place where abseil is actually used) complete, so they thankfully all should just be bin-NMUable. When it does build/passes its tests on ppc64el (again)... Regards, Rene
Bug#1016413: bullseye-pu: package libreoffice/1:7.0.4-4+deb11u3
Hi, Am 28.08.22 um 17:46 schrieb Rene Engelhard: Hi, Am 31.07.22 um 16:44 schrieb Rene Engelhard: This is now https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1016420 (where the upstream bug which that one is marked as forwarded to has also the reasoning why support for < 3.16 was dropped which makes the patch bigger). I now did a minimal patch (attached.) in case the original patch is deemed to big (which I can understand) Should I upload this or the original upstream patch? (I'd personally prefer the latter, but the former also is OK for me) On IRC just now: 20:58 < adsb> _rene_: if you're concerned about time (which it sounds like you are) I'd prefer the version that's easier to reason about (i.e. the minimal one). feel free to upload that (ideally with "bullseye" in the changelog rather than "stable") -> done. Regards, Rene Regards, Rene
Re: uncoordinated abseil transition ( was: Re: Accepted abseil 0~20220623.0-1 (source amd64) into unstable, unstable)
Hi, Am 28.08.22 um 19:58 schrieb Rene Engelhard: Am 28.08.22 um 19:50 schrieb Rene Engelhard: b) is a uncoordinated transiition. libabsl20210324 -> libabsl20220623. # grep-dctrl -FDepends libabsl /var/lib/apt/lists/deb.debian.org_debian_dists_unstable_main_binary-amd64_Packages -sPackage and for source packages: # grep-dctrl -FDepends libabsl /var/lib/apt/lists/deb.debian.org_debian_dists_unstable_main_binary-amd64_Packages -sSource | sort | uniq Source: abseil Source: grpc (1.30.2-3) Source: libgav1 Source: libphonenumber Source: libreoffice Source: libtgowt Source: mozc Source: ortools Quick testing with apt-get -b source (except of libreoffice, which I only did to after the place where abseil is actually used) complete, so they thankfully all should just be bin-NMUable. Regards, Rene
Re: uncoordinated abseil transition ( was: Re: Accepted abseil 0~20220623.0-1 (source amd64) into unstable, unstable)
Hi, Am 28.08.22 um 19:50 schrieb Rene Engelhard: b) is a uncoordinated transiition. libabsl20210324 -> libabsl20220623. # grep-dctrl -FDepends libabsl /var/lib/apt/lists/deb.debian.org_debian_dists_unstable_main_binary-amd64_Packages -sPackage and for source packages: # grep-dctrl -FDepends libabsl /var/lib/apt/lists/deb.debian.org_debian_dists_unstable_main_binary-amd64_Packages -sSource | sort | uniq Source: abseil Source: grpc (1.30.2-3) Source: libgav1 Source: libphonenumber Source: libreoffice Source: libtgowt Source: mozc Source: ortools Regards, Rene
uncoordinated abseil transition ( was: Re: Accepted abseil 0~20220623.0-1 (source amd64) into unstable, unstable)
Hi, Am 28.08.22 um 19:00 schrieb Debian FTP Masters: [...] Maintainer: Benjamin Barenblat Changed-By: Benjamin Barenblat Description: libabsl-dev - extensions to the C++ standard library (development files) libabsl20220623 - extensions to the C++ standard library Closes: 1008730 1012194 Changes: abseil (0~20220623.0-1) unstable; urgency=medium . * New upstream release. (Closes: #1008730, #1012194) This a) needs a bin-NMU to be able to migrate to testing b) is a uncoordinated transiition. libabsl20210324 -> libabsl20220623. # grep-dctrl -FDepends libabsl /var/lib/apt/lists/deb.debian.org_debian_dists_unstable_main_binary-amd64_Packages -sPackage Package: libabsl-dev Package: libgrpc++1 Package: libgrpc10 Package: python3-grpcio Package: libgav1-1 Package: libgav1-bin Package: libgeocoding8 Package: libphonenumber-dev Package: libphonenumber8 Package: libreoffice-core Package: libreoffice-core-nogui Package: libtgowt-dev Package: emacs-mozc-bin Package: fcitx-mozc Package: fcitx5-mozc Package: ibus-mozc Package: mozc-server Package: mozc-utils-gui Package: uim-mozc Package: libortools-dev Package: libortools8 Package: ortools-flatzinc Package: ortools-samples Package: python3-ortools Package: telegram-desktop Package: ycmd Regards, Rene
Bug#1016413: bullseye-pu: package libreoffice/1:7.0.4-4+deb11u3
Hi,
Hrmpf.
This happens if you try to build a minimal patch (and doing the diffs
and tests in different trees) in parallel to sending the diff :/ And
that in time pressure to do it today because I won't have time next week
probably for it and then the timeframe for 11.5 closes...
Am 28.08.22 um 18:46 schrieb Rene Engelhard:
which contained a cut and paste error I introduced when redoing it
after deciding I do the version check again for complenetess' sake...
That doesn't work either. EDS_CHECK_VERSION is not available from only
libebook, we'd need libedataserver for it too.
As I don't want to add that
Reverted that and hardcoded it anyway. >= 3.16 is a given anyway.
Really working patch attached.
Sorry again.
Regards,
Rene
diff --git a/changelog b/changelog
index 41633702..82ecac2d 100644
--- a/changelog
+++ b/changelog
@@ -1,3 +1,10 @@
+libreoffice (1:7.0.4-4+deb11u3) stable; urgency=medium
+
+ * debian/patches/fix-e_book_client_connect_direct_sync-sig.diff:
+as name says (closes: #1016420)
+
+ -- Rene Engelhard Sun, 28 Aug 2022 19:22:27 +0200
+
libreoffice (1:7.0.4-4+deb11u2) stable; urgency=medium
* debian/patches/hrk-euro.diff: add EUR to .hr i18n;
diff --git a/patches/fix-e_book_client_connect_direct_sync-sig.diff
b/patches/fix-e_book_client_connect_direct_sync-sig.diff
new file mode 100644
index ..bc3ecf31
--- /dev/null
+++ b/patches/fix-e_book_client_connect_direct_sync-sig.diff
@@ -0,0 +1,26 @@
+diff --git a/connectivity/source/drivers/evoab2/EApi.h
b/connectivity/source/drivers/evoab2/EApi.h
+index 8c05f95fa2ce..928786d79f00 100644
+--- a/connectivity/source/drivers/evoab2/EApi.h
b/connectivity/source/drivers/evoab2/EApi.h
+@@ -147,7 +147,7 @@ EAPI_EXTERN const gchar* (*eds_check_version) (guint
required_major, guint requi
+ EAPI_EXTERN const gchar* (*e_source_get_uid) (ESource *source);
+ EAPI_EXTERN ESource* (*e_source_registry_ref_source) (ESourceRegistry
*registry, const gchar *uid);
+ EAPI_EXTERN EBookClient* (*e_book_client_new) (ESource *source, GError
**error);
+-EAPI_EXTERN EBookClient* (*e_book_client_connect_direct_sync)
(ESourceRegistry *registry, ESource *source, GCancellable *cancellable, GError
**error);
++EAPI_EXTERN EBookClient* (*e_book_client_connect_direct_sync)
(ESourceRegistry *registry, ESource *source, guint32
wait_for_connected_seconds, GCancellable *cancellable, GError **error);
+ EAPI_EXTERN gboolean (*e_client_open_sync) (EClient *client, gboolean
only_if_exists, GCancellable *cancellable, GError **error);
+ EAPI_EXTERN ESource* (*e_client_get_source) (EClient *client);
+ EAPI_EXTERN gboolean (*e_book_client_get_contacts_sync) (EBookClient *client,
const gchar *sexp, GSList **contacts, GCancellable *cancellable, GError
**error);
+diff --git a/connectivity/source/drivers/evoab2/NResultSet.cxx
b/connectivity/source/drivers/evoab2/NResultSet.cxx
+index 77d53939c1aa..83e792538fc0 100644
+--- a/connectivity/source/drivers/evoab2/NResultSet.cxx
b/connectivity/source/drivers/evoab2/NResultSet.cxx
+@@ -477,7 +477,7 @@ class OEvoabVersion38Helper : public OEvoabVersion36Helper
+ protected:
+ virtual EBookClient * createClient( ESource *pSource ) override
+ {
+-return e_book_client_connect_direct_sync (get_e_source_registry (),
pSource, nullptr, nullptr);
++return e_book_client_connect_direct_sync (get_e_source_registry (),
pSource, 10, nullptr, nullptr);
+ }
+ };
+
diff --git a/patches/series b/patches/series
index fa58e363..69db8a90 100644
--- a/patches/series
+++ b/patches/series
@@ -62,3 +62,4 @@ b0404f80577de9ff69e58390c6f6ef949fdb0139.patch
0002-CVE-2022-26307-make-hash-encoding-match-decoding.patch
0003-CVE-2022-26306-add-Initialization-Vectors-to-passwor.patch
0004-CVE-2022-2630-6-7-add-infobar-to-prompt-to-refresh-t.patch
+fix-e_book_client_connect_direct_sync-sig.diff
Bug#1016413: bullseye-pu: package libreoffice/1:7.0.4-4+deb11u3
Hi,
Am 28.08.22 um 18:37 schrieb Rene Engelhard:
Am 28.08.22 um 17:56 schrieb Rene Engelhard:
Am 28.08.22 um 17:46 schrieb Rene Engelhard:
Am 31.07.22 um 16:44 schrieb Rene Engelhard:
This is now
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1016420 (where
the upstream bug which that one is marked as forwarded to has also
the reasoning why support for < 3.16 was dropped which makes the
patch bigger).
I now did a minimal patch (attached.) in case the original patch is
deemed to big (which I can understand)
Hrmf. doesn't build (for whatever reason). Will investigate...
OK, got it, forgot adapt the internal EApi.h. Patch attached.
which contained a cut and paste error I introduced when redoing it
after deciding I do the version check again for complenetess' sake...
It's tested to use the current block, though.
Nevertheless, correct patch attached.
Regards,
Rene
diff --git a/changelog b/changelog
index 41633702..08449161 100644
--- a/changelog
+++ b/changelog
@@ -1,3 +1,10 @@
+libreoffice (1:7.0.4-4+deb11u3) stable; urgency=medium
+
+ * debian/patches/fix-e_book_client_connect_direct_sync-sig.diff:
+as name says (closes: #1016420)
+
+ -- Rene Engelhard Sun, 28 Aug 2022 18:32:57 +0200
+
libreoffice (1:7.0.4-4+deb11u2) stable; urgency=medium
* debian/patches/hrk-euro.diff: add EUR to .hr i18n;
diff --git a/patches/fix-e_book_client_connect_direct_sync-sig.diff
b/patches/fix-e_book_client_connect_direct_sync-sig.diff
new file mode 100644
index ..a12f915d
--- /dev/null
+++ b/patches/fix-e_book_client_connect_direct_sync-sig.diff
@@ -0,0 +1,32 @@
+diff --git a/connectivity/source/drivers/evoab2/EApi.h
b/connectivity/source/drivers/evoab2/EApi.h
+index 8c05f95fa2ce..daed075ba80b 100644
+--- a/connectivity/source/drivers/evoab2/EApi.h
b/connectivity/source/drivers/evoab2/EApi.h
+@@ -147,7 +147,11 @@ EAPI_EXTERN const gchar* (*eds_check_version) (guint
required_major, guint requi
+ EAPI_EXTERN const gchar* (*e_source_get_uid) (ESource *source);
+ EAPI_EXTERN ESource* (*e_source_registry_ref_source) (ESourceRegistry
*registry, const gchar *uid);
+ EAPI_EXTERN EBookClient* (*e_book_client_new) (ESource *source, GError
**error);
++#if EDS_CHECK_VERSION ( 3, 16, 0)
++EAPI_EXTERN EBookClient* (*e_book_client_connect_direct_sync)
(ESourceRegistry *registry, ESource *source, guint32
wait_for_connected_seconds, GCancellable *cancellable, GError **error);
++#else
+ EAPI_EXTERN EBookClient* (*e_book_client_connect_direct_sync)
(ESourceRegistry *registry, ESource *source, GCancellable *cancellable, GError
**error);
++#endif
+ EAPI_EXTERN gboolean (*e_client_open_sync) (EClient *client, gboolean
only_if_exists, GCancellable *cancellable, GError **error);
+ EAPI_EXTERN ESource* (*e_client_get_source) (EClient *client);
+ EAPI_EXTERN gboolean (*e_book_client_get_contacts_sync) (EBookClient *client,
const gchar *sexp, GSList **contacts, GCancellable *cancellable, GError
**error);
+diff --git a/connectivity/source/drivers/evoab2/NResultSet.cxx
b/connectivity/source/drivers/evoab2/NResultSet.cxx
+index 77d53939c1aa..dc73574d8368 100644
+--- a/connectivity/source/drivers/evoab2/NResultSet.cxx
b/connectivity/source/drivers/evoab2/NResultSet.cxx
+@@ -477,7 +477,10 @@ class OEvoabVersion38Helper : public OEvoabVersion36Helper
+ protected:
+ virtual EBookClient * createClient( ESource *pSource ) override
+ {
+-return e_book_client_connect_direct_sync (get_e_source_registry (),
pSource, nullptr, nullptr);
++ if (eds_check_version( 3, 16, 0 ) == nullptr)
++ return e_book_client_connect_direct_sync (get_e_source_registry
(), pSource, 10, nullptr, nullptr);
++ else
++ return e_book_client_connect_direct_sync (get_e_source_registry
(), pSource, nullptr, nullptr);
+ }
+ };
+
diff --git a/patches/series b/patches/series
index fa58e363..69db8a90 100644
--- a/patches/series
+++ b/patches/series
@@ -62,3 +62,4 @@ b0404f80577de9ff69e58390c6f6ef949fdb0139.patch
0002-CVE-2022-26307-make-hash-encoding-match-decoding.patch
0003-CVE-2022-26306-add-Initialization-Vectors-to-passwor.patch
0004-CVE-2022-2630-6-7-add-infobar-to-prompt-to-refresh-t.patch
+fix-e_book_client_connect_direct_sync-sig.diff
Bug#1016413: bullseye-pu: package libreoffice/1:7.0.4-4+deb11u3
Hi again,
Am 28.08.22 um 17:56 schrieb Rene Engelhard:
Am 28.08.22 um 17:46 schrieb Rene Engelhard:
Am 31.07.22 um 16:44 schrieb Rene Engelhard:
This is now https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1016420
(where the upstream bug which that one is marked as forwarded to has
also the reasoning why support for < 3.16 was dropped which makes the
patch bigger).
I now did a minimal patch (attached.) in case the original patch is
deemed to big (which I can understand)
Hrmf. doesn't build (for whatever reason). Will investigate...
OK, got it, forgot adapt the internal EApi.h. Patch attached.
Regards,
Renediff --git a/changelog b/changelog
index 41633702..08449161 100644
--- a/changelog
+++ b/changelog
@@ -1,3 +1,10 @@
+libreoffice (1:7.0.4-4+deb11u3) stable; urgency=medium
+
+ * debian/patches/fix-e_book_client_connect_direct_sync-sig.diff:
+as name says (closes: #1016420)
+
+ -- Rene Engelhard Sun, 28 Aug 2022 18:32:57 +0200
+
libreoffice (1:7.0.4-4+deb11u2) stable; urgency=medium
* debian/patches/hrk-euro.diff: add EUR to .hr i18n;
diff --git a/patches/fix-e_book_client_connect_direct_sync-sig.diff
b/patches/fix-e_book_client_connect_direct_sync-sig.diff
new file mode 100644
index ..a12f915d
--- /dev/null
+++ b/patches/fix-e_book_client_connect_direct_sync-sig.diff
@@ -0,0 +1,32 @@
+diff --git a/connectivity/source/drivers/evoab2/EApi.h
b/connectivity/source/drivers/evoab2/EApi.h
+index 8c05f95fa2ce..daed075ba80b 100644
+--- a/connectivity/source/drivers/evoab2/EApi.h
b/connectivity/source/drivers/evoab2/EApi.h
+@@ -147,7 +147,11 @@ EAPI_EXTERN const gchar* (*eds_check_version) (guint
required_major, guint requi
+ EAPI_EXTERN const gchar* (*e_source_get_uid) (ESource *source);
+ EAPI_EXTERN ESource* (*e_source_registry_ref_source) (ESourceRegistry
*registry, const gchar *uid);
+ EAPI_EXTERN EBookClient* (*e_book_client_new) (ESource *source, GError
**error);
++#if EDS_CHECK_VERSION ( 3, 16, 0)
++EAPI_EXTERN EBookClient* (*e_book_client_connect_direct_sync)
(ESourceRegistry *registry, ESource *source, guint32
wait_for_connected_seconds, GCancellable *cancellable, GError **error);
++#else
+ EAPI_EXTERN EBookClient* (*e_book_client_connect_direct_sync)
(ESourceRegistry *registry, ESource *source, GCancellable *cancellable, GError
**error);
++#endif
+ EAPI_EXTERN gboolean (*e_client_open_sync) (EClient *client, gboolean
only_if_exists, GCancellable *cancellable, GError **error);
+ EAPI_EXTERN ESource* (*e_client_get_source) (EClient *client);
+ EAPI_EXTERN gboolean (*e_book_client_get_contacts_sync) (EBookClient *client,
const gchar *sexp, GSList **contacts, GCancellable *cancellable, GError
**error);
+diff --git a/connectivity/source/drivers/evoab2/NResultSet.cxx
b/connectivity/source/drivers/evoab2/NResultSet.cxx
+index 77d53939c1aa..dc73574d8368 100644
+--- a/connectivity/source/drivers/evoab2/NResultSet.cxx
b/connectivity/source/drivers/evoab2/NResultSet.cxx
+@@ -477,7 +477,10 @@ class OEvoabVersion38Helper : public OEvoabVersion36Helper
+ protected:
+ virtual EBookClient * createClient( ESource *pSource ) override
+ {
+-return e_book_client_connect_direct_sync (get_e_source_registry (),
pSource, nullptr, nullptr);
++ if (eds_check_version( 3, 16, 0 ) == nullptr)
++ return e_book_client_connect_direct_sync (get_e_source_registry
(), pSource, 10, nullptr, nullptr);
++ else
++ return e_book_client_connect_direct_sync (get_e_source_registry
(), pSource, 10, nullptr, nullptr);
+ }
+ };
+
diff --git a/patches/series b/patches/series
index fa58e363..69db8a90 100644
--- a/patches/series
+++ b/patches/series
@@ -62,3 +62,4 @@ b0404f80577de9ff69e58390c6f6ef949fdb0139.patch
0002-CVE-2022-26307-make-hash-encoding-match-decoding.patch
0003-CVE-2022-26306-add-Initialization-Vectors-to-passwor.patch
0004-CVE-2022-2630-6-7-add-infobar-to-prompt-to-refresh-t.patch
+fix-e_book_client_connect_direct_sync-sig.diff
Bug#1016413: bullseye-pu: package libreoffice/1:7.0.4-4+deb11u3
Hi again, Am 28.08.22 um 17:46 schrieb Rene Engelhard: Am 31.07.22 um 16:44 schrieb Rene Engelhard: This is now https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1016420 (where the upstream bug which that one is marked as forwarded to has also the reasoning why support for < 3.16 was dropped which makes the patch bigger). I now did a minimal patch (attached.) in case the original patch is deemed to big (which I can understand) Hrmf. doesn't build (for whatever reason). Will investigate... Regards, Rene
Bug#1016413: bullseye-pu: package libreoffice/1:7.0.4-4+deb11u3
Hi,
Am 31.07.22 um 16:44 schrieb Rene Engelhard:
This is now https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1016420
(where the upstream bug which that one is marked as forwarded to has
also the reasoning why support for < 3.16 was dropped which makes the
patch bigger).
I now did a minimal patch (attached.) in case the original patch is
deemed to big (which I can understand)
Should I upload this or the original upstream patch?
(I'd personally prefer the latter, but the former also is OK for me)
Regards,
Rene
diff --git a/changelog b/changelog
index 41633702..e1f8835a 100644
--- a/changelog
+++ b/changelog
@@ -1,3 +1,11 @@
+libreoffice (1:7.0.4-4+deb11u3) stable; urgency=medium
+
+ * debian/patches/fix-e_book_client_connect_direct_sync-sig.diff:
+as name says; just use the minimal change with added
+eds_check_version check (closes: #1016420)
+
+ -- Rene Engelhard Sun, 28 Aug 2022 16:37:25 +0200
+
libreoffice (1:7.0.4-4+deb11u2) stable; urgency=medium
* debian/patches/hrk-euro.diff: add EUR to .hr i18n;
diff --git a/patches/fix-e_book_client_connect_direct_sync-sig.diff
b/patches/fix-e_book_client_connect_direct_sync-sig.diff
new file mode 100644
index ..ea815e1e
--- /dev/null
+++ b/patches/fix-e_book_client_connect_direct_sync-sig.diff
@@ -0,0 +1,16 @@
+diff --git a/connectivity/source/drivers/evoab2/NResultSet.cxx
b/connectivity/source/drivers/evoab2/NResultSet.cxx
+index 77d53939c1aa..ef64891803c2 100644
+--- a/connectivity/source/drivers/evoab2/NResultSet.cxx
b/connectivity/source/drivers/evoab2/NResultSet.cxx
+@@ -477,7 +477,10 @@ class OEvoabVersion38Helper : public OEvoabVersion36Helper
+ protected:
+ virtual EBookClient * createClient( ESource *pSource ) override
+ {
+-return e_book_client_connect_direct_sync (get_e_source_registry (),
pSource, nullptr, nullptr);
++ if (eds_check_version( 3, 16, 0 ) == nullptr)
++ return e_book_client_connect_direct_sync (get_e_source_registry
(), pSource, 10, nullptr, nullptr);
++ else
++ return e_book_client_connect_direct_sync (get_e_source_registry
(), pSource, nullptr, nullptr);
+ }
+ };
+
diff --git a/patches/series b/patches/series
index fa58e363..69db8a90 100644
--- a/patches/series
+++ b/patches/series
@@ -62,3 +62,4 @@ b0404f80577de9ff69e58390c6f6ef949fdb0139.patch
0002-CVE-2022-26307-make-hash-encoding-match-decoding.patch
0003-CVE-2022-26306-add-Initialization-Vectors-to-passwor.patch
0004-CVE-2022-2630-6-7-add-infobar-to-prompt-to-refresh-t.patch
+fix-e_book_client_connect_direct_sync-sig.diff
Bug#1016080: buster-pu: package libreoffice/:6.1.5-3+deb10u8
Hi, Am 25.08.22 um 21:05 schrieb Adam D. Barratt: To clarify here, are you suggesting that we should skip this change for buster? Yes, given that we'd need a further update even more tiny and the next release is the final one I don't think this warrants a full libreoffice build. Sorry for this unneeded request. > (and, as you say, assume people will want to use newer versions in any case.) Indeed. Just didn't want to close myself, but we could do so and ignore this for buster. Regards, Rene
Bug#1016413: pu bug for reference
Hi, Am 04.08.22 um 12:58 schrieb Rene Engelhard: just for reference: a stable update for this is requested in http://bugs.debian.org/1016413 oops, should have been gone to #1016420 obviously (too hot...) Regards, Rene
Bug#1016413: pu bug for reference
just for reference: a stable update for this is requested in http://bugs.debian.org/1016413
Bug#1016413: bullseye-pu: package libreoffice/1:7.0.4-4+deb11u3
Hi, Am 31.07.22 um 12:33 schrieb Rene Engelhard: [ Reason ] It seems the volution adress book is broken since 2015 due to a evolution change. Apparently noone noticed until 2021, where I backported the patch but then actually forgot to request a stable update [ Impact ] It stays broken. [ Tests ] None, ttbomk. Except manually connecting to a evolution adress book. [ Risks ] Quite a big change which removes compat with old, not-compatible anymore evolution and thus also has a bit of code cleanup upstream. But it's a upstream commit and there ttbomk was no complaints afterwards that it didn't work again. This is now https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1016420 (where the upstream bug which that one is marked as forwarded to has also the reasoning why support for < 3.16 was dropped which makes the patch bigger). Regards, Ren
Bug#1016413: Acknowledgement (bullseye-pu: package libreoffice/1:7.0.4-4+deb11u3)
Hi,
oops, forgot the diff.
Here it comes. (with s/UNRELEASED/stable/ of course before the upload.)
Regards,
Rene
diff --git a/changelog b/changelog
index 41633702..850dd234 100644
--- a/changelog
+++ b/changelog
@@ -1,3 +1,10 @@
+libreoffice (1:7.0.4-4+deb11u3) UNRELEASED; urgency=medium
+
+ * debian/patches/fix-e_book_client_connect_direct_sync-sig.diff:
+as name says; from libreoffice-7-2 branch
+
+ -- Rene Engelhard Sun, 31 Jul 2022 11:04:32 +0200
+
libreoffice (1:7.0.4-4+deb11u2) stable; urgency=medium
* debian/patches/hrk-euro.diff: add EUR to .hr i18n;
diff --git a/patches/fix-e_book_client_connect_direct_sync-sig.diff
b/patches/fix-e_book_client_connect_direct_sync-sig.diff
new file mode 100644
index ..7aef915e
--- /dev/null
+++ b/patches/fix-e_book_client_connect_direct_sync-sig.diff
@@ -0,0 +1,417 @@
+From 3b9210195b8d2ac9861a1e607455ff9d16eb68fd Mon Sep 17 00:00:00 2001
+From: Julien Nabet
+Date: Wed, 15 Dec 2021 22:45:47 +0100
+Subject: [PATCH] tdf#137101: fix e_book_client_connect_direct_sync signature
+ in Evolution
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+since it changed in 2015, see all details from tdf#137101
+Thank you to krumelmonster for having spotted this!
+
++ some cleanup to remove all eds_check_version calls
+and dependencies
+
+Change-Id: Iaf2437f8f5c04ab9674a380dac1dfb16ec8c7201
+Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126898
+Tested-by: Jenkins
+Tested-by: Caolán McNamara
+Reviewed-by: Caolán McNamara
+(cherry picked from commit 0661c796c767802c114441ad9a17fd0979d72ef4)
+Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126920
+---
+ connectivity/source/drivers/evoab2/EApi.cxx | 54 +---
+ connectivity/source/drivers/evoab2/EApi.h | 2 +-
+ .../drivers/evoab2/NDatabaseMetaData.cxx | 121 +
+ .../source/drivers/evoab2/NResultSet.cxx | 125 +-
+ 4 files changed, 39 insertions(+), 263 deletions(-)
+
+diff --git a/connectivity/source/drivers/evoab2/EApi.cxx
b/connectivity/source/drivers/evoab2/EApi.cxx
+index 12096bdade87..ebe710dedb57 100644
+--- a/connectivity/source/drivers/evoab2/EApi.cxx
b/connectivity/source/drivers/evoab2/EApi.cxx
+@@ -23,16 +23,7 @@
+ static const char *eBookLibNames[] = {
+ "libebook-1.2.so.20", // evolution-data-server 3.33.2+
+ "libebook-1.2.so.19", // evolution-data-server 3.24+
+-"libebook-1.2.so.16",
+-"libebook-1.2.so.15",
+-"libebook-1.2.so.14", // bumped again (evolution-3.6)
+-"libebook-1.2.so.13", // bumped again (evolution-3.4)
+-"libebook-1.2.so.12", // bumped again
+-"libebook-1.2.so.10", // bumped again
+-"libebook-1.2.so.9", // evolution-2.8
+-"libebook-1.2.so.5", // evolution-2.4 and 2.6+
+-"libebook-1.2.so.3", // evolution-2.2
+-"libebook.so.8" // evolution-2.0
++"libebook-1.2.so.16"
+ };
+
+ typedef void (*SymbolFunc) ();
+@@ -71,19 +62,6 @@ static const ApiMap aCommonApiMap[] =
+ SYM_MAP( e_book_query_field_exists )
+ };
+
+-//< 3.6 api
+-static const ApiMap aOldApiMap[] =
+-{
+-SYM_MAP( e_book_get_addressbooks ),
+-SYM_MAP( e_book_get_uri ),
+-SYM_MAP( e_book_authenticate_user ),
+-SYM_MAP( e_source_group_peek_base_uri),
+-SYM_MAP( e_source_peek_name ),
+-SYM_MAP( e_source_get_property ),
+-SYM_MAP( e_source_list_peek_groups ),
+-SYM_MAP( e_source_group_peek_sources )
+-};
+-
+ //>= 3.6 api
+ static const ApiMap aNewApiMap[] =
+ {
+@@ -101,12 +79,6 @@ static const ApiMap aNewApiMap[] =
+ SYM_MAP( e_client_util_free_object_slist )
+ };
+
+-//== indirect read access (3.6 only)
+-static const ApiMap aClientApiMap36[] =
+-{
+-SYM_MAP( e_book_client_new )
+-};
+-
+ //>= direct read access API (>= 3.8)
+ static const ApiMap aClientApiMap38[] =
+ {
+@@ -144,33 +116,14 @@ bool EApiInit()
+
+ if (tryLink( aModule, eBookLibNames[ j ], aCommonApiMap))
+ {
+-if (eds_check_version( 3, 6, 0 ) != nullptr)
++if (tryLink( aModule, eBookLibNames[ j ], aNewApiMap))
+ {
+-if (tryLink( aModule, eBookLibNames[ j ], aOldApiMap))
++if (tryLink( aModule, eBookLibNames[ j ], aClientApiMap38))
+ {
+ aModule.release();
+ return true;
+ }
+ }
+-else if (tryLink( aModule, eBookLibNames[ j ], aNewApiMap))
+-{
+-if (eds_check_version( 3, 7, 6 ) != nullptr)
+-{
+-if (tryLink( aModule, eBookLibNames[ j ],
aClientApiMap36))
+-{
+-aModule.release();
+-return true;
+-}
+-}
+-else
+-{
+-
Bug#1016413: bullseye-pu: package libreoffice/1:7.0.4-4+deb11u3
Package: release.debian.org Severity: normal Tags: bullseye User: release.debian@packages.debian.org Usertags: pu Hi, I split the evolution fix out of #1016037 since that one admittedly is a bit bug and can be debatable to unblock the HRK fix and the CVE updates in deb11u2. [ Reason ] It seems the volution adress book is broken since 2015 due to a evolution change. Apparently noone noticed until 2021, where I backported the patch but then actually forgot to request a stable update [ Impact ] It stays broken. [ Tests ] None, ttbomk. Except manually connecting to a evolution adress book. [ Risks ] Quite a big change which removes compat with old, not-compatible anymore evolution and thus also has a bit of code cleanup upstream. But it's a upstream commit and there ttbomk was no complaints afterwards that it didn't work again. [ Checklist ] [x] *all* changes are documented in the d/changelog [x] I reviewed all changes and I approve them [x] attach debdiff against the package in (old)stable [x] the issue is verified as fixed in unstable Debdiff attached compared to deb11u2- [ Changes ] simple backport of upstream commit 3b9210195b8d2ac9861a1e607455ff9d16eb68fd Regards, Rene
Bug#1016037: bullseye-pu: package libreoffice/1:7.0.4-4+deb11u2 (was: bullseye-pu: package libreoffice/1:7.0.4-4+deb11u1)
Hi,
[ sorry for the back and forth and my impatience but I want to get this
done. ]
I backed out the (admittedly big) evolution fix and just kept the Euro
fix and the CVEs:
[ Reason ]
1) Croatia will join the Eurozone on 2023-01-01. I think we should
prepare.
TODO: After (or shortly before) 2023-01-01 we then can do a point
release update to switch the default...
2) CVE-2021-25636 was no-DSA for bullseye but given we do an update
anyway we can just include it
3) I talked with Moritz on 2022-07-25 and CVE-2022-2630{5,6,7} are also
no-DSA.
While we are at it we can fix it too here
[ Impact ]
for 1) EUR isn't supported in .hr locale
for 2) and 3) stays vulnerable (though it's minor)
[ Tests ]
None, ttbomk.
[ Risks ]
for 1) trivial, and doesn't yet affect the default
for 2) and 3), the usual risks of backporting security fixes (though
there were not much adaptions needed)
[ Checklist ]
[x] *all* changes are documented in the d/changelog
[x] I reviewed all changes and I approve them
[x] attach debdiff against the package in (old)stable
[x] the issue is verified as fixed in unstable
[ Changes ]
I just added the verbatim upstream commits. (Made to apply and build for
the CVE-2022-2630{5,6,7} fixes, well, actually taking one part of a
patch from distro/lhm/libreoffice-6-4+backports branch (Munich))
Debdiff attached.
[ Other info ]
As said, for 1) we need a new update to switch the default later.
Since those issues are probably unconcontroversial I did a upload
according to the "new" rules already.
Regards,
Renediff -Nru libreoffice-7.0.4/debian/changelog libreoffice-7.0.4/debian/changelog
--- libreoffice-7.0.4/debian/changelog 2021-10-10 12:37:28.0 +0200
+++ libreoffice-7.0.4/debian/changelog 2022-07-26 13:19:49.0 +0200
@@ -1,3 +1,17 @@
+libreoffice (1:7.0.4-4+deb11u2) stable; urgency=medium
+
+ * debian/patches/hrk-euro.diff: add EUR to .hr i18n;
+add HRK<->EUR conversion rate to Calc and the Euro Wizard
+ * debian/patches/b0404f80577de9ff69e58390c6f6ef949fdb0139.patch: fix
+CVE-2021-25636
+ * debian/patches/0001-CVE-2022-26305-compare-authors-using-Thumbprint.patch,
+debian/patches/0002-CVE-2022-26307-make-hash-encoding-match-decoding.patch
+
debian/patches/0003-CVE-2022-26306-add-Initialization-Vectors-to-passwor.patch
+
debian/patches/0004-CVE-2022-2630-6-7-add-infobar-to-prompt-to-refresh-t.patch:
+fix CVE-2022-2630{5,6,7}
+
+ -- Rene Engelhard Tue, 26 Jul 2022 13:19:49 +0200
+
libreoffice (1:7.0.4-4+deb11u1) bullseye-security; urgency=high
* backport fixes from libreoffice-7-0 branch:
diff -Nru
libreoffice-7.0.4/debian/patches/0001-CVE-2022-26305-compare-authors-using-Thumbprint.patch
libreoffice-7.0.4/debian/patches/0001-CVE-2022-26305-compare-authors-using-Thumbprint.patch
---
libreoffice-7.0.4/debian/patches/0001-CVE-2022-26305-compare-authors-using-Thumbprint.patch
1970-01-01 01:00:00.0 +0100
+++
libreoffice-7.0.4/debian/patches/0001-CVE-2022-26305-compare-authors-using-Thumbprint.patch
2022-07-26 13:16:17.0 +0200
@@ -0,0 +1,63 @@
+From 77f30ada1156ca1e1357776fea8e9dc113f6898d Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Caol=C3=A1n=20McNamara?=
+Date: Thu, 3 Mar 2022 14:22:37 +
+Subject: [PATCH 1/4] CVE-2022-26305 compare authors using Thumbprint
+
+Change-Id: I338f58eb07cbf0a3d13a7dafdaddac09252a8546
+Reviewed-on: https://gerrit.libreoffice.org/c/core/+/130929
+Tested-by: Jenkins
+Reviewed-by: Miklos Vajna
+(cherry picked from commit 65442205b5b274ad309308162f150f8d41648f72)
+Reviewed-on: https://gerrit.libreoffice.org/c/core/+/130866
+Reviewed-by: Michael Stahl
+(cherry picked from commit a7aaa78acea4c1d51283c2fce54ff9f5339026f8)
+---
+ .../component/documentdigitalsignatures.cxx | 23 +++
+ 1 file changed, 19 insertions(+), 4 deletions(-)
+
+diff --git a/xmlsecurity/source/component/documentdigitalsignatures.cxx
b/xmlsecurity/source/component/documentdigitalsignatures.cxx
+index b9066ea92cac..5a21c8421bec 100644
+--- a/xmlsecurity/source/component/documentdigitalsignatures.cxx
b/xmlsecurity/source/component/documentdigitalsignatures.cxx
+@@ -19,9 +19,10 @@
+
+ #include
+
+-#include
++#include
+ #include
+ #include
++#include
+ #include
+ #include
+ #include
+@@ -666,9 +667,23 @@ sal_Bool DocumentDigitalSignatures::isAuthorTrusted(
+ Sequence< SvtSecurityOptions::Certificate > aTrustedAuthors =
SvtSecurityOptions().GetTrustedAuthors();
+
+ return std::any_of(aTrustedAuthors.begin(), aTrustedAuthors.end(),
+-[, ](const SvtSecurityOptions::Certificate&
rAuthor) {
+-return xmlsecurity::EqualDistinguishedNames(rAuthor[0],
xAuthor->getIssuerName())
+-&& ( rAuthor[1] == sSerialNum );
++[this, , ](const SvtSecurityOptions::Certificate&
rAuthor) {
++if (!xmlsecurity::EqualDistinguishedNames(rAuthor[0],
xAuthor->getIssuerName()))
++
Bug#1016080: buster-pu: package libreoffice/:6.1.5-3+deb10u8
Hi, Am 26.07.22 um 19:11 schrieb Rene Engelhard: actually this is quite a small update for a big package. Should we really do it (and the default change)? Or should we assume people don't use LO from oldstable anymore and either use bullseye or the bullseye version backported to buster? Filing for completeness' sake, though. I didn't have on radar that buster supports ends in a few days anyway. And doing the default change in LTS then even makes less sense for a effectively diff --git a/i18npool/source/localedata/data/hr_HR.xml b/i18npool/source/localedata/data/hr_HR.xml index 4de83e5535cd..eec5a9e98779 100644 --- a/i18npool/source/localedata/data/hr_HR.xml +++ b/i18npool/source/localedata/data/hr_HR.xml @@ -414,7 +414,7 @@ - + HRK kn HRK @@ -422,7 +422,7 @@ 2 - + EUR € EUR only... Hmm. In any case: [ ] the issue is verified as fixed in unstable Update: [x] the issue is verified as fixed in unstable This is not yet fixed in unstable, that will happen with the upload of 7.4.0 rc2 (or someting later) to it This now happened and thus 2) is fixed in unstable too - with 1:7.4.0~rc2-2. Regards, Rene
Bug#1016037: bullseye-pu: package libreoffice/1:7.0.4-4+deb11u2 (was: bullseye-pu: package libreoffice/1:7.0.4-4+deb11u1)
Hi, Am 26.07.22 um 13:24 schrieb Rene Engelhard: [ Checklist ] [x] *all* changes are documented in the d/changelog [x] I reviewed all changes and I approve them [x] attach debdiff against the package in (old)stable [ ] the issue is verified as fixed in unstable Update: [x] the issue is verified as fixed in unstable (2) is not yet fixed in unstable, that will happen with the upload of 7.4.0 rc2 (or someting later) to it This now happened and thus 2) is fixed in unstable too - with 1:7.4.0~rc2-2. Regards, Rene
Bug#1016080: buster-pu: package libreoffice/:6.1.5-3+deb10u8
Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu
Hi,
actually this is quite a small update for a big package. Should we
really do it (and the default change)? Or should we assume people don't
use LO from oldstable anymore and either use bullseye or the bullseye
version backported to buster?
Filing for completeness' sake, though.
[ Reason ]
Croatia will join the Eurozone on 2023-01-01. I think we should
prepare.
TODO: After (or shortly before) 2023-01-01 we then can do a point
release update to switch the default...
[ Impact ]
EUR isn't supported in .hr locale
[ Tests ]
None, ttbomk.
[ Risks ]
None. trivial, and doesn't yet affect the default
[ Checklist ]
[x] *all* changes are documented in the d/changelog
[x] I reviewed all changes and I approve them
[x] attach debdiff against the package in (old)stable
[ ] the issue is verified as fixed in unstable
This is not yet fixed in unstable, that will happen with the upload of
7.4.0 rc2 (or someting later) to it
[ Changes ]
See above. I just added the verbatim upstream commits.
Debdiff:
$ export TMPDIR=~/tmp; debdiff libreoffice_6.1.5-3+deb10u7.dsc
libreoffice_6.1.5-3+deb10u8.dsc
dpkg-source: Warnung: unsigniertes Quellpaket wird extrahiert
(/home/rene/Debian/Pakete/LibreOffice/libreoffice/libreoffice_6.1.5-3+deb10u8.dsc)
diff -Nru libreoffice-6.1.5/debian/changelog libreoffice-6.1.5/debian/changelog
--- libreoffice-6.1.5/debian/changelog 2021-03-08 13:13:24.0 +0100
+++ libreoffice-6.1.5/debian/changelog 2022-07-26 18:54:43.0 +0200
@@ -1,3 +1,10 @@
+libreoffice (1:6.1.5-3+deb10u8) buster; urgency=medium
+
+ * debian/patches/hrk-euro.diff: add EUR to .hr i18n;
+add HRK<->EUR conversion rate to Calc and the Euro Wizard
+
+ -- Rene Engelhard Tue, 26 Jul 2022 18:54:43 +0200
+
libreoffice (1:6.1.5-3+deb10u7) buster; urgency=medium
* debian/patches/fix-PYTHONPATH.diff: backport upstream fix to
diff -Nru libreoffice-6.1.5/debian/patches/hrk-euro.diff
libreoffice-6.1.5/debian/patches/hrk-euro.diff
--- libreoffice-6.1.5/debian/patches/hrk-euro.diff 1970-01-01
01:00:00.0 +0100
+++ libreoffice-6.1.5/debian/patches/hrk-euro.diff 2022-07-26
18:54:22.0 +0200
@@ -0,0 +1,156 @@
+From 7c4b2db21ef77b37daf234ac1ab9989234606a22 Mon Sep 17 00:00:00 2001
+From: Eike Rathke
+Date: Fri, 22 Jul 2022 22:12:02 +0200
+Subject: Resolves: tdf#150011 Add HRK Croatian Kuna conversion to EUR Euro
+
+TODO: switch defaults before 2023-01-01 in
+i18npool/source/localedata/data/hr_HR.xml
+
+Change-Id: Ifc62aefbc8c9fe8bbf044f61ae4fd6eeff692185
+Reviewed-on: https://gerrit.libreoffice.org/c/core/+/137371
+Reviewed-by: Eike Rathke
+Tested-by: Jenkins
+---
+ i18npool/source/localedata/data/hr_HR.xml | 8
+ officecfg/registry/data/org/openoffice/Office/Calc.xcu | 11 +++
+ sc/source/core/tool/interpr2.cxx | 3 ++-
+ 3 files changed, 21 insertions(+), 1 deletion(-)
+
+diff --git a/i18npool/source/localedata/data/hr_HR.xml
b/i18npool/source/localedata/data/hr_HR.xml
+index 0c493131e16b..4de83e5535cd 100644
+--- a/i18npool/source/localedata/data/hr_HR.xml
b/i18npool/source/localedata/data/hr_HR.xml
+@@ -421,6 +421,14 @@
+ Hrvatska Kuna
+ 2
+
++
++
++ EUR
++ €
++ EUR
++ Euro
++ 2
++
+
+
+
+diff --git a/officecfg/registry/data/org/openoffice/Office/Calc.xcu
b/officecfg/registry/data/org/openoffice/Office/Calc.xcu
+index a62d06512704..eda60fe6c434 100644
+--- a/officecfg/registry/data/org/openoffice/Office/Calc.xcu
b/officecfg/registry/data/org/openoffice/Office/Calc.xcu
+@@ -228,6 +228,17 @@
+ 3.45280
+
+
++
++
++EUR
++
++
++HRK
++
++
++7.53450
++
++
+
+
+
+diff --git a/sc/source/core/tool/interpr2.cxx
b/sc/source/core/tool/interpr2.cxx
+index 31c42a4b728a..67fcd9f787f8 100644
+--- a/sc/source/core/tool/interpr2.cxx
b/sc/source/core/tool/interpr2.cxx
+@@ -3235,7 +3235,8 @@ static bool lclConvertMoney( const OUString&
aSearchUnit, double& rfRate, int& r
+ { "SKK", 30.1260, 2 },
+ { "EEK", 15.6466, 2 },
+ { "LVL", 0.702804, 2 },
+-{ "LTL", 3.45280, 2 }
++{ "LTL", 3.45280, 2 },
++{ "HRK", 7.53450, 2 }
+ };
+
+ for (const auto & i : aConvertTable)
+--
+cgit v1.2.1
+
+From b1a2f727ca99ecd3402d4b051b99cbfd24266e59 Mon Sep 17 00:00:00 2001
+From: Eike Rathke
+Date: Fri, 22 Jul 2022 22:17:11 +0200
+Subject: Related: tdf#150011 Add HRK Croatian Kuna to Euro conversion wizard
+
+Maybe just for completeness, it's removed from menu but might be
+callable as macro.
+
+Change-Id: Iade0be845186d3deb2f00f4aaa230c0b344cea72
+Reviewed-on: https://gerrit.libreoffice.org/c/core/+/137372
Bug#1016037: bullseye-pu: package libreoffice/1:7.0.4-4+deb11u2 (was: bullseye-pu: package libreoffice/1:7.0.4-4+deb11u1)
Hi,
[ redoing all the information for better clarity in the bugreport ]
[ Reason ]
1) It seems the evolution adress book is broken since 2015 due to a
evolution change. Apparently noone noticed until 2021, where I
backported the patch but then actually forgot to request a stable update
2) Croatia will join the Eurozone on 2023-01-01. I think we should
prepare.
TODO: After (or shortly before) 2023-01-01 we then can do a point
release update to switch the default...
3) CVE-2021-25636 was no-DSA for bullseye but given we do an update
anyway we can just include it
4) I just talked with Moritz and CVE-2022-2630{5,6,7} are also no-DSA.
While we are at it we can fix it too here
[ Impact ]
for 1) it stays broken.
for 2) EUR isn't supported in .hr locale
for 3) and 4) stays vulnerable (though it's minor)
[ Tests ]
None, ttbomk.
[ Risks ]
for 2) trivial, and doesn't yet affect the default
for 1) it is a bigger patch but upstream since 2021. No regression known
and if it should regress, it can't get more broken than "broken".
[ Checklist ]
[x] *all* changes are documented in the d/changelog
[x] I reviewed all changes and I approve them
[x] attach debdiff against the package in (old)stable
[ ] the issue is verified as fixed in unstable
(2) is not yet fixed in unstable, that will happen with the upload of
7.4.0 rc2 (or someting later) to it
[ Changes ]
See above. I just added the verbatim upstream commits. (Made to apply
and build for the CVE-2022-2630{5,6,7} fixes)
Debdiff attached.
[ Other info ]
As said, for 2) we need a new update to switch the default later.
Regards,
Renediff --git a/changelog b/changelog
index bdd1d149..ea05cdd3 100644
--- a/changelog
+++ b/changelog
@@ -1,3 +1,19 @@
+libreoffice (1:7.0.4-4+deb11u2) stable; urgency=medium
+
+ * debian/patches/fix-e_book_client_connect_direct_sync-sig.diff:
+as name says; from libreoffice-7-2 branch
+ * debian/patches/hrk-euro.diff: add EUR to .hr i18n;
+add HRK<->EUR conversion rate to Calc and the Euro Wizard
+ * debian/patches/b0404f80577de9ff69e58390c6f6ef949fdb0139.patch: fix
+CVE-2021-25636
+ * debian/patches/0001-CVE-2022-26305-compare-authors-using-Thumbprint.patch,
+debian/patches/0002-CVE-2022-26307-make-hash-encoding-match-decoding.patch
+debian/patches/0003-CVE-2022-26306-add-Initialization-Vectors-to-passwor.patch
+debian/patches/0004-CVE-2022-2630-6-7-add-infobar-to-prompt-to-refresh-t.patch:
+fix CVE-2022-2630{5,6,7}
+
+ -- Rene Engelhard Tue, 26 Jul 2022 13:19:49 +0200
+
libreoffice (1:7.0.4-4+deb11u1) bullseye-security; urgency=high
* backport fixes from libreoffice-7-0 branch:
diff --git a/patches/0001-CVE-2022-26305-compare-authors-using-Thumbprint.patch b/patches/0001-CVE-2022-26305-compare-authors-using-Thumbprint.patch
new file mode 100644
index ..e02b110f
--- /dev/null
+++ b/patches/0001-CVE-2022-26305-compare-authors-using-Thumbprint.patch
@@ -0,0 +1,63 @@
+From 77f30ada1156ca1e1357776fea8e9dc113f6898d Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Caol=C3=A1n=20McNamara?=
+Date: Thu, 3 Mar 2022 14:22:37 +
+Subject: [PATCH 1/4] CVE-2022-26305 compare authors using Thumbprint
+
+Change-Id: I338f58eb07cbf0a3d13a7dafdaddac09252a8546
+Reviewed-on: https://gerrit.libreoffice.org/c/core/+/130929
+Tested-by: Jenkins
+Reviewed-by: Miklos Vajna
+(cherry picked from commit 65442205b5b274ad309308162f150f8d41648f72)
+Reviewed-on: https://gerrit.libreoffice.org/c/core/+/130866
+Reviewed-by: Michael Stahl
+(cherry picked from commit a7aaa78acea4c1d51283c2fce54ff9f5339026f8)
+---
+ .../component/documentdigitalsignatures.cxx | 23 +++
+ 1 file changed, 19 insertions(+), 4 deletions(-)
+
+diff --git a/xmlsecurity/source/component/documentdigitalsignatures.cxx b/xmlsecurity/source/component/documentdigitalsignatures.cxx
+index b9066ea92cac..5a21c8421bec 100644
+--- a/xmlsecurity/source/component/documentdigitalsignatures.cxx
b/xmlsecurity/source/component/documentdigitalsignatures.cxx
+@@ -19,9 +19,10 @@
+
+ #include
+
+-#include
++#include
+ #include
+ #include
++#include
+ #include
+ #include
+ #include
+@@ -666,9 +667,23 @@ sal_Bool DocumentDigitalSignatures::isAuthorTrusted(
+ Sequence< SvtSecurityOptions::Certificate > aTrustedAuthors = SvtSecurityOptions().GetTrustedAuthors();
+
+ return std::any_of(aTrustedAuthors.begin(), aTrustedAuthors.end(),
+-[, ](const SvtSecurityOptions::Certificate& rAuthor) {
+-return xmlsecurity::EqualDistinguishedNames(rAuthor[0], xAuthor->getIssuerName())
+-&& ( rAuthor[1] == sSerialNum );
++[this, , ](const SvtSecurityOptions::Certificate& rAuthor) {
++if (!xmlsecurity::EqualDistinguishedNames(rAuthor[0], xAuthor->getIssuerName()))
++return false;
++if (rAuthor[1] != sSerialNum)
++return false;
++
++Docu
Bug#1016037: bullseye-pu: package libreoffice/1:7.0.4-4+deb11u1
Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
[ Reason ]
1) It seems the volution adress book is broken since 2015 due to a evolution
change. Apparently noone noticed until 2021, where I backported the patch
but then
actually forgot to request a stable update
2) Croatia will join the Eurozone on 2023-01-01. I think we should
prepare.
TODO: After (or shortly before) 2023-01-01 we then can do a point release
update
to switch the default...
[ Impact ]
for 1) it stays broken.
for 2) EUR isn't supported in .hr locale
[ Tests ]
None, ttbomk.
[ Risks ]
for 2) trivial, and doesn't yet affect the default
for 1) it is a bigger patch but upstream since 2021. No regression known
and if it should regress, it can't get more broken than "broken".
[ Checklist ]
[x] *all* changes are documented in the d/changelog
[x] I reviewed all changes and I approve them
[x] attach debdiff against the package in (old)stable
[ ] the issue is verified as fixed in unstable
(2) is not yet fixed in unstable, that will happen with the upload of
7.4.0 rc2 (or someting later) to it
[ Changes ]
See above. I just added the verbatim upstream commits.
Debdiff attached.
[ Other info ]
As said, for 2) we need a new update to switch the default later.
Regards,
Rene
diff --git a/changelog b/changelog
index bdd1d149..2baf8b2f 100644
--- a/changelog
+++ b/changelog
@@ -1,3 +1,12 @@
+libreoffice (1:7.0.4-4+deb11u2) stable; urgency=medium
+
+ * debian/patches/fix-e_book_client_connect_direct_sync-sig.diff:
+as name says; from libreoffice-7-2 branch
+ * debian/patches/hrk-euro.diff: add EUR to .hr i18n;
+add HRK<->EUR conversion rate to Calc and the Euro Wizard
+
+ -- Rene Engelhard Mon, 25 Jul 2022 17:47:13 +0200
+
libreoffice (1:7.0.4-4+deb11u1) bullseye-security; urgency=high
* backport fixes from libreoffice-7-0 branch:
diff --git a/patches/fix-e_book_client_connect_direct_sync-sig.diff
b/patches/fix-e_book_client_connect_direct_sync-sig.diff
new file mode 100644
index ..7aef915e
--- /dev/null
+++ b/patches/fix-e_book_client_connect_direct_sync-sig.diff
@@ -0,0 +1,417 @@
+From 3b9210195b8d2ac9861a1e607455ff9d16eb68fd Mon Sep 17 00:00:00 2001
+From: Julien Nabet
+Date: Wed, 15 Dec 2021 22:45:47 +0100
+Subject: [PATCH] tdf#137101: fix e_book_client_connect_direct_sync signature
+ in Evolution
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+since it changed in 2015, see all details from tdf#137101
+Thank you to krumelmonster for having spotted this!
+
++ some cleanup to remove all eds_check_version calls
+and dependencies
+
+Change-Id: Iaf2437f8f5c04ab9674a380dac1dfb16ec8c7201
+Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126898
+Tested-by: Jenkins
+Tested-by: Caolán McNamara
+Reviewed-by: Caolán McNamara
+(cherry picked from commit 0661c796c767802c114441ad9a17fd0979d72ef4)
+Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126920
+---
+ connectivity/source/drivers/evoab2/EApi.cxx | 54 +---
+ connectivity/source/drivers/evoab2/EApi.h | 2 +-
+ .../drivers/evoab2/NDatabaseMetaData.cxx | 121 +
+ .../source/drivers/evoab2/NResultSet.cxx | 125 +-
+ 4 files changed, 39 insertions(+), 263 deletions(-)
+
+diff --git a/connectivity/source/drivers/evoab2/EApi.cxx
b/connectivity/source/drivers/evoab2/EApi.cxx
+index 12096bdade87..ebe710dedb57 100644
+--- a/connectivity/source/drivers/evoab2/EApi.cxx
b/connectivity/source/drivers/evoab2/EApi.cxx
+@@ -23,16 +23,7 @@
+ static const char *eBookLibNames[] = {
+ "libebook-1.2.so.20", // evolution-data-server 3.33.2+
+ "libebook-1.2.so.19", // evolution-data-server 3.24+
+-"libebook-1.2.so.16",
+-"libebook-1.2.so.15",
+-"libebook-1.2.so.14", // bumped again (evolution-3.6)
+-"libebook-1.2.so.13", // bumped again (evolution-3.4)
+-"libebook-1.2.so.12", // bumped again
+-"libebook-1.2.so.10", // bumped again
+-"libebook-1.2.so.9", // evolution-2.8
+-"libebook-1.2.so.5", // evolution-2.4 and 2.6+
+-"libebook-1.2.so.3", // evolution-2.2
+-"libebook.so.8" // evolution-2.0
++"libebook-1.2.so.16"
+ };
+
+ typedef void (*SymbolFunc) ();
+@@ -71,19 +62,6 @@ static const ApiMap aCommonApiMap[] =
+ SYM_MAP( e_book_query_field_exists )
+ };
+
+-//< 3.6 api
+-static const ApiMap aOldApiMap[] =
+-{
+-SYM_MAP( e_book_get_addressbooks ),
+-SYM_MAP( e_book_get_uri ),
+-SYM_MAP( e_book_authenticate_user ),
+-SYM_MAP( e_source_group_peek_base_uri),
+-SYM_MAP( e_source_peek_name ),
+-SYM_MAP( e_source_get_property ),
+-SYM_MAP( e_source_list_peek_groups ),
+-SYM_MAP( e_source_group_peek_sources )
+-};
+-
+ //>= 3.6 api
+ static const ApiMap
Bug#1007905: transition: icu
Hi, Am 15.04.22 um 08:57 schrieb László Böszörményi (GCS): On Fri, Apr 15, 2022 at 8:48 AM Rene Engelhard wrote: Am 13.04.22 um 17:52 schrieb Rene Engelhard: Am 13.04.22 um 17:24 schrieb László Böszörményi (GCS): LibreOffice self-testing, especially its break iterator test fails for the Lao language. https://cgit.freedesktop.org/libreoffice/core/commit/?id=263961306ede0656ebb7904034a2172615ce81d0 Nevermind, that one is already there. But it fails because it does != 70 and 71 still is affected. So we just need to extend it. Submitted it uptream in https://gerrit.libreoffice.org/c/core/+/133063/1/i18npool/qa/cppunit/test_breakiterator.cxx and will backport it to the 7.3.3 packages. Your patch has a glitch. The U_ICU_VERSION_MAJOR_NUM check must be strictly lower than 70 for word boundary equal to nine. If it's ICU version 70 or higher, the else case should be hit. Ie: #if (U_ICU_VERSION_MAJOR_NUM < 70) is the correct check IMHO. Ah, right, not enough coffee yet obviously. :) Thanks for pointing this out. Regards, Rene
Bug#1007905: transition: icu
Hi again, Am 13.04.22 um 17:52 schrieb Rene Engelhard: Am 13.04.22 um 17:24 schrieb László Böszörményi (GCS): LibreOffice self-testing, especially its break iterator test fails for the Lao language. https://cgit.freedesktop.org/libreoffice/core/commit/?id=263961306ede0656ebb7904034a2172615ce81d0 Nevermind, that one is already there. But it fails because it does != 70 and 71 still is affected. So we just need to extend it. Submitted it uptream in https://gerrit.libreoffice.org/c/core/+/133063/1/i18npool/qa/cppunit/test_breakiterator.cxx and will backport it to the 7.3.3 packages. Regards, Rene
Bug#1007905: transition: icu
Hi, Am 13.04.22 um 17:24 schrieb László Böszörményi (GCS): LibreOffice self-testing, especially its break iterator test fails for the Lao language. https://cgit.freedesktop.org/libreoffice/core/commit/?id=263961306ede0656ebb7904034a2172615ce81d0 We could backport the needed stuff to 7.3. Otherwise everything was fine. But I think I might redo the rebuilds (only on amd64 now) to test everything with the final release of ICU. If that's not mandatory, I think ICU is quite OK for a transition soon. If python3-defaults was done (or actually even progressing...)... Regards, Rene
Re: Accepted nspr 2:4.32-2 (source) into unstable
Hi, Am 21.11.21 um 00:04 schrieb Debian FTP Masters: > nspr (2:4.32-2) unstable; urgency=medium > . > * debian/libnspr4-dev.links.in, debian/control: Remove > xulrunner-nspr.pc, > which breaks libxmlsec1-dev (<= 1.2.33-1). At least thanks for adding the Breaks: directly. But can you please *coordinate* this? Or at least tell the maintainer? (Your .changes file/debian-devel-changes is not the mechanism to tell other maintainers of changes. That one is not a must-read list.) You should have mailed the maintainer at least. Again "not amused". In this case one even can't argue with "assume good faith" anymore since we already had that with nss back then and again you deliberately did this. Filed #1000299 for the bin-NMU a few hours ago. Regards, Rene
Bug#1000299: Accepted nspr 2:4.32-2 (source) into unstable
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu Hi, Am 21.11.21 um 00:04 schrieb Debian FTP Masters: > nspr (2:4.32-2) unstable; urgency=medium > . > * debian/libnspr4-dev.links.in, debian/control: Remove > xulrunner-nspr.pc, > which breaks libxmlsec1-dev (<= 1.2.33-1). > [...] Again no coordination whatsoever but at least he added a Breaks: from the beginning... (see also https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=998339). This makes any package using xmlsec1-nss.pc FTBFS. (admittedly that is just libreoffice.) This time there's no handy upstream release to be updated so there should be a bin-NMU. So please nmu xmlsec1_1.2.32-1 . ANY . unstable . -m "rebuild against nspr 2:4.32-2 to fix xmlsec1-nss.pc" dw xmlsec1_1.2.32-1 . mips mipsel . -m 'libnspr4-dev (>= 2:4.32-2)' (and some debian-ports arch, does ANY work?) Regards, Rene
Bug#998339: nmu: xmlsec1_1.2.32-2
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu [ nss maintainer X-Debbugs-Cc'ed ] Hi, nss 2:3.72-1 uploaded this morning did: nss (2:3.72-1) unstable; urgency=medium [...] * debian/libnss3-dev.links.in: Remove xulrunner-nss.pc. [...] Without any coordination whatsoever. This now results in stuff using libxmlsec1-dev (the nss variant) to FTBFS: $ pkg-config --libs xmlsec1-nss Package xulrunner-nss was not found in the pkg-config search path. Perhaps you should add the directory containing `xulrunner-nss.pc' to the PKG_CONFIG_PATH environment variable Package 'xulrunner-nss', required by 'xmlsec1-nss', not found cf. also the libreoffice autopkgtest which runs ./configure and needs the build-deps for this: https://ci.debian.net/data/autopkgtest/testing/amd64/libr/libreoffice/16373758/log.gz https://ci.debian.net/data/autopkgtest/testing/armhf/libr/libreoffice/16373879/log.gz https://ci.debian.net/data/autopkgtest/testing/i386/libr/libreoffice/16373931/log.gz https://ci.debian.net/data/autopkgtest/unstable/amd64/libr/libreoffice/16377878/log.gz https://ci.debian.net/data/autopkgtest/unstable/amd64/libr/libreoffice/16349711/log.gz Thankfully libxmlsec seems to write into that file what it detects at configure stage (in current sid nss.pc) and thus a bin-NMU should suffice. So please nmu xmlsec1_1.2.32-2 . ANY . unstable . -m "rebuild against nss 3.72-1 to fix xmlsec1-nss.pc" Regards, Rene
Re: uncoordinated box2d transition (was: Re: Accepted box2d 2.4.1-2 (source) into unstable)
Hi, Am 05.09.21 um 14:44 schrieb Rene Engelhard: > Yes, it's slideshow. Transitions based on physics: Sorry, not transitions but animation effects in slideshows. Regards Rene
Re: uncoordinated box2d transition (was: Re: Accepted box2d 2.4.1-2 (source) into unstable)
Am 05.09.21 um 14:37 schrieb Markus Koschany: > Hi, > > Am Sonntag, dem 05.09.2021 um 14:21 +0200 schrieb Rene Engelhard: >> [...]But not for libreoffice, and libreoffice DOES use box2d since 7.1.x >> which is in testing. > > Sorry, I thought that was a copy error and you only meant to rebuild > caveexpress. Ok, if I had known that I would have requested a proper > transition. ? I explicitely mentioned my upstream commit *to libreoffice* in one of the last mails... Besides that, there is grep-dctrl and https://release.debian.org/transitions/html/auto-box2d.html showing libreoffice is a r-dep needing to be rebuilt. Since months. Regards, Rene
Re: uncoordinated box2d transition (was: Re: Accepted box2d 2.4.1-2 (source) into unstable)
Hi, Am 05.09.21 um 14:37 schrieb Markus Koschany: > However I would consider not build-depending on a 2d physics > library like box2d. Usually this library is embedded in custom games because Yeah, libreoffice upstream also uses a internal code copy... > whenever there are changes to the library the physical effects can change too. > Thus the shared version currently works with caveexpress but future versions > may break your use case (slideshows?[1]) even without big changes like a > SONAME > bump. Then someone needs to fix this, and if upstreams breaks compat something needs to be done. (And be it fixing box2d to stay compatible. It's a separate project after all.) Yes, it's slideshow. Transitions based on physics: https://quwex.com/gsoc20-final-report/ And yes, I *do* follow the "don't use internal code copies" rule :) Regards, Rene
Re: uncoordinated box2d transition (was: Re: Accepted box2d 2.4.1-2 (source) into unstable)
Hi, Am 05.09.21 um 14:10 schrieb Markus Koschany: > Hello, > > Am Sonntag, dem 05.09.2021 um 09:48 +0200 schrieb Rene Engelhard: > [...] >> without any coordination or a transition approved on debian-release. >> That a transition would be needed was viisble since months at >> https://release.debian.org/transitions/html/auto-box2d.html. >> >> >> @release: please bin-NMU ( at least libreoffice builds, didn't try >> caveexpress): >> >> nmu libreoffice . ANY . -m 'rebuild against libbox2d2' ] >> >> nmu libreoffice . ANY . experimental . -m 'changelog entry/dep-wait expr.' ] >> >> >> caveexpress is the only other affected package - and (expectedly) >> doesn't build anymore: > [...] > > There is no coordination needed because I am the maintainer of box2d and > caveexpress. Another upload of caveexpress will follow today. A bin-nmu is not > necessary and should have never been requested. But not for libreoffice, and libreoffice DOES use box2d since 7.1.x which is in testing. Regards, Rene
Re: uncoordinated box2d transition (was: Re: Accepted box2d 2.4.1-2 (source) into unstable)
Hi, Am 05.09.21 um 09:48 schrieb Rene Engelhard: > caveexpress is the only other affected package - and (expectedly) > doesn't build anymore: > > [...] > > [20%] Building CXX object > src/modules/physics/CMakeFiles/physics.dir/DebugRenderer.cpp.o > cd > /home/rene/LibreOffice/git/master/caveexpress-2.5.1/obj-i686-linux-gnu/src/modules/physics > && /usr/bin/ccache /usr/bin/c++ -DHAVE_LUA_H > -DPKGDATADIR=\"/usr/share/games\" > -I/home/rene/LibreOffice/git/master/caveexpress-2.5.1/obj-i686-linux-gnu > -I/home/rene/LibreOffice/git/master/caveexpress-2.5.1/src > -I/home/rene/LibreOffice/git/master/caveexpress-2.5.1/src/modules > -I/usr/include/SDL2 -I/usr/include/lua5.2 -I/usr/include/box2d -g -O2 > -ffile-prefix-map=/home/rene/LibreOffice/git/master/caveexpress-2.5.1=. > -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time > -D_FORTIFY_SOURCE=2 -std=c++11 -fno-exceptions -fno-rtti -g -O2 > -ffile-prefix-map=/home/rene/LibreOffice/git/master/caveexpress-2.5.1=. > -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time > -D_FORTIFY_SOURCE=2 -g -Wcast-qual -Wcast-align -Wpointer-arith > -Wno-long-long -Wno-multichar -Wshadow -Wall -Wextra -Wno-sign-compare > -Wno-unused-parameter -Wreturn-type -Wwrite-strings -Wno-variadic-macros > -Wno-unknown-pragmas -pthread -Wnon-virtual-dtor -o > CMakeFiles/physics.dir/DebugRenderer.cpp.o -c > /home/rene/LibreOffice/git/master/caveexpress-2.5.1/src/modules/physics/DebugRenderer.cpp > In file included from > /home/rene/LibreOffice/git/master/caveexpress-2.5.1/src/modules/physics/DebugRenderer.cpp:1: > /home/rene/LibreOffice/git/master/caveexpress-2.5.1/src/modules/physics/DebugRenderer.h:7:10: > fatal error: Box2D/Box2D.h: No such file or directory > 7 | #include > | ^~~ > compilation terminated. > > [...] > This is #993710 now. Regards, Rene
Re: uncoordinated box2d transition (was: Re: Accepted box2d 2.4.1-2 (source) into unstable)
Hi, Am 05.09.21 um 09:48 schrieb Rene Engelhard: > nmu libreoffice . ANY . -m 'rebuild against libbox2d2' ] > > nmu libreoffice . ANY . experimental . -m 'changelog entry/dep-wait expr.' ] Sorry, cut and waste.. nmu libreoffice . ANY . -m 'rebuild against libbox2d2' ] nmu libreoffice . ANY . experimental . -m 'rebuild against libbox2d2' ] (I'll probably upload rc2 mid-next week) All this will be blocked by gpgme1.0, though... Regards, Rene
uncoordinated box2d transition (was: Re: Accepted box2d 2.4.1-2 (source) into unstable)
Hi, Am 05.09.21 um 01:18 schrieb Debian FTP Masters: > [...] Maintainer: Debian Games Team > > Changed-By: Markus Koschany > Changes: > box2d (2.4.1-2) unstable; urgency=medium > . > * Upload to unstable. > * Declare compliance with Debian Policy 4.6.0. > * Mark libbox2d-doc Multi-Arch:foreign and libbox2d-dev > Multi-Arch:same. [...] without any coordination or a transition approved on debian-release. That a transition would be needed was viisble since months at https://release.debian.org/transitions/html/auto-box2d.html. @release: please bin-NMU ( at least libreoffice builds, didn't try caveexpress): nmu libreoffice . ANY . -m 'rebuild against libbox2d2' ] nmu libreoffice . ANY . experimental . -m 'changelog entry/dep-wait expr.' ] caveexpress is the only other affected package - and (expectedly) doesn't build anymore: [...] [20%] Building CXX object src/modules/physics/CMakeFiles/physics.dir/DebugRenderer.cpp.o cd /home/rene/LibreOffice/git/master/caveexpress-2.5.1/obj-i686-linux-gnu/src/modules/physics && /usr/bin/ccache /usr/bin/c++ -DHAVE_LUA_H -DPKGDATADIR=\"/usr/share/games\" -I/home/rene/LibreOffice/git/master/caveexpress-2.5.1/obj-i686-linux-gnu -I/home/rene/LibreOffice/git/master/caveexpress-2.5.1/src -I/home/rene/LibreOffice/git/master/caveexpress-2.5.1/src/modules -I/usr/include/SDL2 -I/usr/include/lua5.2 -I/usr/include/box2d -g -O2 -ffile-prefix-map=/home/rene/LibreOffice/git/master/caveexpress-2.5.1=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -std=c++11 -fno-exceptions -fno-rtti -g -O2 -ffile-prefix-map=/home/rene/LibreOffice/git/master/caveexpress-2.5.1=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -g -Wcast-qual -Wcast-align -Wpointer-arith -Wno-long-long -Wno-multichar -Wshadow -Wall -Wextra -Wno-sign-compare -Wno-unused-parameter -Wreturn-type -Wwrite-strings -Wno-variadic-macros -Wno-unknown-pragmas -pthread -Wnon-virtual-dtor -o CMakeFiles/physics.dir/DebugRenderer.cpp.o -c /home/rene/LibreOffice/git/master/caveexpress-2.5.1/src/modules/physics/DebugRenderer.cpp In file included from /home/rene/LibreOffice/git/master/caveexpress-2.5.1/src/modules/physics/DebugRenderer.cpp:1: /home/rene/LibreOffice/git/master/caveexpress-2.5.1/src/modules/physics/DebugRenderer.h:7:10: fatal error: Box2D/Box2D.h: No such file or directory 7 | #include | ^~~ compilation terminated. [...] (That was what i expected and because of which I did https://cgit.freedesktop.org/libreoffice/core/commit/?id=d0601cd3812cbcdaa0decf81c81d73d41a6ccb91 at LibreOffice upstream long ago.) Regards, Rene
Bug#988906: unblock: libreoffice/1:7.0.4-4
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package libreoffice
This fixes the upgrade buster->bullseye. See #985297.
Quoting Andreas Beckmann:
"
One problem is Breaks in one package being handled first (by
deconfiguratio) and subsequent occurrences of Conflicts in another
package will be ignored for deconfigured packages (and removal will not
happen).
We can fix most of the upgrade issues by propagating the Conflicts to
the package with the Breaks, s.t. deconfiguration does not happen but
removal does happen immediately. Unfortunately this does not work if
there are too many packages the would need to be removed together since
dpkg does not get the optimal ordering for doing that. These are mostly
upgrade paths with libreoffice-impress or libreoffice-report-builder
installed.
So in the end I resorted to not using
dpkg-maintscript-helper dir_to_symlink
as I had initially suggested but fixing it up manually in the postinst.
I've running various buster->bullseye upgrade scenarios (with and
without recommends, direct distupgrade vs upgrade && dist-upgrade)
with the patched packages as upgrade targets. I've rerun all piuparts
tests that had libreoffice-common installed and haven't seen any more
problems with the patched packages.
"
(https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=985297#43)
It also includes a minor fix for #982274 which I didn't revert for this
upload - in contrast to other changes I had in git already when this
came up. The profile is in complain mode per default anyway.
Already is 20/20 days old:
libreoffice (1:7.0.4-3 to 1:7.0.4-4)
Maintainer: Debian LibreOffice Maintainers
Migration status for libreoffice (1:7.0.4-3 to 1:7.0.4-4): BLOCKED: Needs
an approval (either due to a freeze, the source suite or a manual hint)
Issues preventing migration:
blocked by freeze: is a key package (Follow the freeze policy when applying
for an unblock)
Additional info:
Updating libreoffice fixes old bugs: #985297
Piuparts tested OK -
https://piuparts.debian.org/sid/source/libr/libreoffice.html
autopkgtest for libreoffice/1:7.0.4-4: amd64: Pass, arm64: Test in progress
(will not be considered a regression), armhf: Pass, i386: Pass, ppc64el: Test
in progress (will not be considered a regression)
20 days old (needed 20 days)
(arm64 and ppc64el are blacklisted in autopkgtest due to infrastructural
issues)
Diff:
diff -Nru libreoffice-7.0.4/debian/changelog libreoffice-7.0.4/debian/changelog
--- libreoffice-7.0.4/debian/changelog 2021-01-03 18:54:17.0 +0100
+++ libreoffice-7.0.4/debian/changelog 2021-05-01 13:50:48.0 +0200
@@ -1,3 +1,20 @@
+libreoffice (1:7.0.4-4) unstable; urgency=medium
+
+ * debian/patches/apparmor-updates.diff: allow one more digit in temp
+files (closes: #982274)
+ * debian/control.in, debian/libreoffice-common.{maintscript,postinst.in}:
+apply patch from Adreas Beckmann to fix upgrade buster->bullseye
+- libreoffice-core: Copy some Conflicts from libreoffice-common for
smoother
+ upgrades from buster. Dpkg will otherwise ignore Conflicts that are
+ encountered later against a package that is already deconfigured.
+- libreoffice-common: Do not use dir_to_symlink for
+ /usr/lib/libreoffice/share/registry, the Breaks/Conflicts cascade does
not
+ work reliable here to ensure all packages previously shipping files there
+ are either removed or upgraded first, but not just deconfigured. Fix up
+ the symlink in postinst instead. (Closes: #985297)
+
+ -- Rene Engelhard Sat, 01 May 2021 13:50:48 +0200
+
libreoffice (1:7.0.4-3) unstable; urgency=medium
* debian/tests/control.in: *really* add libreoffice-writer dependency
diff -Nru libreoffice-7.0.4/debian/control libreoffice-7.0.4/debian/control
--- libreoffice-7.0.4/debian/control2021-01-03 18:54:17.0 +0100
+++ libreoffice-7.0.4/debian/control2021-05-01 13:50:48.0 +0200
@@ -451,6 +451,15 @@
libreoffice-core-nogui,
libreoffice-filter-binfilter,
libreoffice-mysql-connector (<< 1:6.2.0~)
+# for bullseye, copied from libreoffice-common, see #985297
+ ,
+ libreoffice-base (<< 1:7.0.0~alpha~),
+ libreoffice-calc (<< 1:7.0.0~alpha~),
+ libreoffice-draw (<< 1:7.0.0~alpha~),
+ libreoffice-impress (<< 1:7.0.0~alpha~),
+ libreoffice-math (<< 1:7.0.0~alpha~),
+ libreoffice-report-builder (<< 1:7.0.0~alpha~),
+ libreoffice-writer (<< 1:7.0.0~alpha~),
Replaces: libreoffice-avmedia-backend-gstreamer,
libreoffice-common (<< 1:6.3.0~rc1~),
libreoffice-core-nogui,
diff -Nru libreoffice-7.0.4/debian/control.in
libreoffice-7.0.4/debian/control.in
--- libreoffice-7.0.4/debian/control.in 2020-12-31 11:27:09.0 +0100
+++ libreoffice-7.0.4/debian/control.in 2021-05-01 13:1
Bug#984790: buster-pu: package libreoffice/1:6.1.5-3+deb10u7
Hi, Am 13.03.21 um 19:57 schrieb Adam D. Barratt: > Control: tags -1 + confirmed > > On Mon, 2021-03-08 at 13:26 +0100, Rene Engelhard wrote: >> +libreoffice (1:6.1.5-3+deb10u7) buster; urgency=medium >> + >> + * debian/patches/fix-PYTHONPATH.diff: backport upstream fix to >> +not leave a bare trailing : in PYTHONPATH as it causes >> unconditional >> +loading of encodings.py from . (closes: #984703) >> > Please go ahead. Done, thanks. Regards, Rene
Bug#984790: buster-pu: package libreoffice/1:6.1.5-3+deb10u7
Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu
Hi,
see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=984703.
The Security Team suggests to fix this via the next point release
instead of a DSA, so here it is :-)
Diff:
diff -Nru libreoffice-6.1.5/debian/changelog libreoffice-6.1.5/debian/changelog
--- libreoffice-6.1.5/debian/changelog 2020-02-01 15:13:43.0 +0100
+++ libreoffice-6.1.5/debian/changelog 2021-03-08 13:13:24.0 +0100
@@ -1,3 +1,11 @@
+libreoffice (1:6.1.5-3+deb10u7) buster; urgency=medium
+
+ * debian/patches/fix-PYTHONPATH.diff: backport upstream fix to
+not leave a bare trailing : in PYTHONPATH as it causes unconditional
+loading of encodings.py from . (closes: #984703)
+
+ -- Rene Engelhard Mon, 08 Mar 2021 13:13:24 +0100
+
libreoffice (1:6.1.5-3+deb10u6) buster; urgency=medium
* debian/patches/glm-0.9.9-ctor.diff: add from master, fix opengl slide
diff -Nru libreoffice-6.1.5/debian/patches/fix-PYTHONPATH.diff
libreoffice-6.1.5/debian/patches/fix-PYTHONPATH.diff
--- libreoffice-6.1.5/debian/patches/fix-PYTHONPATH.diff1970-01-01
01:00:00.0 +0100
+++ libreoffice-6.1.5/debian/patches/fix-PYTHONPATH.diff2021-03-08
00:15:24.0 +0100
@@ -0,0 +1,66 @@
+From f463cbd6ea2fd8ab80b812425eb05ae83fa6a426 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Caol=C3=A1n=20McNamara?=
+Date: Fri, 19 Jun 2020 11:32:00 +0100
+Subject: tdf#121384 don't leave a bare trailing : in PYTHONPATH
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+and don't insert any empty path entries if that situation
+was to arise
+
+Change-Id: I8d8183485f457c3e4385181fee07390c4bfef603
+Reviewed-on: https://gerrit.libreoffice.org/c/core/+/96707
+Reviewed-by: Tomáš Chvátal
+Reviewed-by: Adolfo Jayme Barrientos
+Tested-by: Jenkins
+(cherry picked from commit b72705d5391b849fc70a0a4cac33523c0ea5d054)
+Reviewed-on: https://gerrit.libreoffice.org/c/core/+/96803
+Tested-by: Stephan Bergmann
+Reviewed-by: Stephan Bergmann
+---
+ pyuno/source/loader/pyuno_loader.cxx | 14 --
+ 1 file changed, 12 insertions(+), 2 deletions(-)
+
+diff --git a/pyuno/source/loader/pyuno_loader.cxx
b/pyuno/source/loader/pyuno_loader.cxx
+index ffdb81143961..e35148f8ddbc 100644
+--- a/pyuno/source/loader/pyuno_loader.cxx
b/pyuno/source/loader/pyuno_loader.cxx
+@@ -145,6 +145,7 @@ static void setPythonHome ( const OUString & pythonHome )
+ static void prependPythonPath( const OUString & pythonPathBootstrap )
+ {
+ OUStringBuffer bufPYTHONPATH( 256 );
++bool bAppendSep = false;
+ sal_Int32 nIndex = 0;
+ while( true )
+ {
+@@ -160,15 +161,24 @@ static void prependPythonPath( const OUString &
pythonPathBootstrap )
+ }
+ OUString systemPath;
+ osl_getSystemPathFromFileURL( fileUrl.pData, &(systemPath.pData) );
+-bufPYTHONPATH.append( systemPath );
+-bufPYTHONPATH.append( static_cast(SAL_PATHSEPARATOR) );
++if (!systemPath.isEmpty())
++{
++if (bAppendSep)
++
bufPYTHONPATH.append(static_cast(SAL_PATHSEPARATOR));
++bufPYTHONPATH.append(systemPath);
++bAppendSep = true;
++}
+ if( nNew == -1 )
+ break;
+ nIndex = nNew + 1;
+ }
+ const char * oldEnv = getenv( "PYTHONPATH");
+ if( oldEnv )
++{
++if (bAppendSep)
++bufPYTHONPATH.append( static_cast(SAL_PATHSEPARATOR)
);
+ bufPYTHONPATH.append( OUString(oldEnv, strlen(oldEnv),
osl_getThreadTextEncoding()) );
++}
+
+ OUString envVar("PYTHONPATH");
+ OUString envValue(bufPYTHONPATH.makeStringAndClear());
+--
+cgit v1.2.1
+
diff -Nru libreoffice-6.1.5/debian/patches/series
libreoffice-6.1.5/debian/patches/series
--- libreoffice-6.1.5/debian/patches/series 2020-02-01 14:28:40.0
+0100
+++ libreoffice-6.1.5/debian/patches/series 2021-03-08 00:19:35.0
+0100
@@ -65,3 +65,4 @@
allow-link-updates-in-an-intermediate-linked-document.diff
Postgresql-12-no-adsrc.diff
glm-0.9.9-ctor.diff
+fix-PYTHONPATH.diff
Regards,
Rene
Re: Bug#964613: liborcus: FTBFS: dh_auto_test: error: make -j4 check VERBOSE=1 returned exit code 2
On Sun, Sep 13, 2020 at 11:44:59AM +0200, Rene Engelhard wrote: > Nevermind, I just remembered I have those "Debian Janitor" changes > pending. Will do a source upload. Done now. (And a new liborcus with bumped build-dep.) Regards, Rene
Re: Bug#964613: liborcus: FTBFS: dh_auto_test: error: make -j4 check VERBOSE=1 returned exit code 2
On Sun, Sep 13, 2020 at 10:36:26AM +0200, Rene Engelhard wrote: > @-release: please > > nmu libixion . ANY . -m 'rebuild with mdds >= 1.6.0 (closes: #964613)' Nevermind, I just remembered I have those "Debian Janitor" changes pending. Will do a source upload. Regards, Rene
Re: Bug#964613: liborcus: FTBFS: dh_auto_test: error: make -j4 check VERBOSE=1 returned exit code 2
Hi, I forwarded it upstream to https://gitlab.com/orcus/orcus/-/issues/124 and it seems that it does not fail if one rebuilds libixion first. So that means that this bug could be solved by bin-NMUing libxion. (mdds is header-only, and you would want to have some way of expressing "if orcus is built with x, rebuild ixion with x first" (at least for this specific mdds version) which ttbomk is not possible to express. On Sat, Sep 12, 2020 at 01:02:58PM +0200, Rene Engelhard wrote: > It *does* work though with liborcus 0.16.0 which I just uploaded to NEW, > so we probably should upload that one to unstable ASAP if it cleared NEW > (and transition LO to it, upstream it's only in the tree for 7.1.0 which > is unfortunately too late for bullseye.) That also means that mdds 0.17.0/ixion 0.16/orcus 0.16 just works because of course you build the new ixion before the new orcus... @-release: please nmu libixion . ANY . -m 'rebuild with mdds >= 1.6.0 (closes: #964613)' Regards, Rene
Bug#960046: transition: sane-backends
Hi, On Fri, May 08, 2020 at 07:11:09PM +0200, Jörg Frings-Fürst wrote: > libreoffice Note libreoffice only Suggests it (and it dlopen()s libsane.so.1). A rebuild will change the Suggests since https://salsa.debian.org/libreoffice-team/libreoffice/libreoffice/-/commit/a11f5b7381097ea0ae9a3e03db909f4075628935 (2 years ago, when the last rename was attempted.) but this hasn't to be done immediately. So you either can bin-NMU it or not, it will pick the right library up on the next upload. regards, Rene
Bug#950918: buster-pu: package libreoffice/1:6.1.5-3+deb10u6
Hi, On Thu, Mar 05, 2020 at 07:18:34PM +, Adam D. Barratt wrote: > On Sat, 2020-02-08 at 11:06 +0100, Rene Engelhard wrote: > > #916846 was filed pre-buster but I have to admit I cheated against it > > being > > RC by merging the OpenGL transitions (it*s not a important part > > anyway, > > "normal" transitions just suffice.) into > > -impress, making this a important bug only :-) > > > > Please go ahead. Uploaded, thanks. Regards, Rene
Bug#950918: buster-pu: package libreoffice/1:6.1.5-3+deb10u6
Package: release.debian.org Severity: normal Tags: buster User: release.debian@packages.debian.org Usertags: pu Hi, #916846 was filed pre-buster but I have to admit I cheated against it being RC by merging the OpenGL transitions (it*s not a important part anyway, "normal" transitions just suffice.) into -impress, making this a important bug only :-) Anyways, I saw https://cgit.freedesktop.org/libreoffice/core/commit/?id=fb27784fcbd3383a7b2648714de19ae5f3818fa5 recently so this is finally fixed and should be fixed in stable, too. (sid is fixed with 1:6.4.1~rc1-1) Debdiff attached. Regards, Rene -- System Information: Debian Release: 10.2 APT prefers stable APT policy: (990, 'stable'), (500, 'stable-updates') Architecture: arm64 (aarch64) Kernel: Linux 4.19.0-6-arm64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_CRAP Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled diff -Nru libreoffice-6.1.5/debian/changelog libreoffice-6.1.5/debian/changelog --- libreoffice-6.1.5/debian/changelog 2019-10-31 18:26:41.0 +0100 +++ libreoffice-6.1.5/debian/changelog 2020-02-01 15:13:43.0 +0100 @@ -1,3 +1,10 @@ +libreoffice (1:6.1.5-3+deb10u6) buster; urgency=medium + + * debian/patches/glm-0.9.9-ctor.diff: add from master, fix opengl slide +transitions with glm >= 0.9.9 (closes: #917927) + + -- Rene Engelhard Sat, 01 Feb 2020 15:13:43 +0100 + libreoffice (1:6.1.5-3+deb10u5) buster; urgency=medium * debian/patches/Postgresql-12-no-adsrc.diff: add from diff -Nru libreoffice-6.1.5/debian/patches/glm-0.9.9-ctor.diff libreoffice-6.1.5/debian/patches/glm-0.9.9-ctor.diff --- libreoffice-6.1.5/debian/patches/glm-0.9.9-ctor.diff1970-01-01 01:00:00.0 +0100 +++ libreoffice-6.1.5/debian/patches/glm-0.9.9-ctor.diff2020-02-01 14:28:25.0 +0100 @@ -0,0 +1,36 @@ +From fb27784fcbd3383a7b2648714de19ae5f3818fa5 Mon Sep 17 00:00:00 2001 +From: =?UTF-8?q?Caol=C3=A1n=20McNamara?= +Date: Fri, 31 Jan 2020 21:45:11 + +Subject: opengl slide transitions not working with glm >= GLM 0.9.9.0 +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +tracked it down to... + +Removed default initialization, use GLM_FORCE_CTOR_INIT to restore the old behavior +so adding in GLM_FORCE_CTOR_INIT to get them working again + +Change-Id: I1c6e7d8eb748fce40f0c518ff708708e5fb1e3d2 +Reviewed-on: https://gerrit.libreoffice.org/c/core/+/87789 +Tested-by: Jenkins +Reviewed-by: Caolán McNamara +--- + slideshow/Library_OGLTrans.mk | 1 + + 1 file changed, 1 insertion(+) + +diff --git a/slideshow/Library_OGLTrans.mk b/slideshow/Library_OGLTrans.mk +index 4eca2a1ecaa3..9b64181d6a46 100644 +--- a/slideshow/Library_OGLTrans.mk b/slideshow/Library_OGLTrans.mk +@@ -17,6 +17,7 @@ endif + + $(eval $(call gb_Library_add_defs,OGLTrans,\ + -DGLM_FORCE_RADIANS \ ++-DGLM_FORCE_CTOR_INIT \ + )) + + $(eval $(call gb_Library_use_sdk_api,OGLTrans)) +-- +cgit v1.2.1 + diff -Nru libreoffice-6.1.5/debian/patches/series libreoffice-6.1.5/debian/patches/series --- libreoffice-6.1.5/debian/patches/series 2019-10-31 18:26:23.0 +0100 +++ libreoffice-6.1.5/debian/patches/series 2020-02-01 14:28:40.0 +0100 @@ -64,3 +64,4 @@ Improve-check.diff allow-link-updates-in-an-intermediate-linked-document.diff Postgresql-12-no-adsrc.diff +glm-0.9.9-ctor.diff
Bug#949187: transition: python3.8
On Wed, Feb 05, 2020 at 01:26:31PM +, Simon McVittie wrote: > On Wed, 05 Feb 2020 at 08:18:41 +0100, rene.engelh...@mailbox.org wrote: > > Thanks, yes, that prevents the install of the "old" > > gobject-introspection with the new python3 from experimental. > > Sorry, I wasn't thinking straight (I blame post-FOSDEM illness). That > isn't actually what you need if you want to port to python3.8 Actually, no, I just wanted to prevent it FTBFSing when the default changes and gobject-introspection wasn't yet rebuilt. LibreOffice also only builds dor the default. (With a shitload of hackery it is possible to build pyuno twice/thrice etc. but given there*s a LO part of it this will not be coinstallable, defeating the purpose.) Regards, Rene
Bug#949187: transition: python3.8
Hi, Am 4. Februar 2020 23:27:13 MEZ schrieb Simon McVittie : >On Tue, 04 Feb 2020 at 21:20:07 +0100, Rene Engelhard wrote: >> root@frodo:/# g-ir-scanner >... >> ModuleNotFoundError: No module named 'giscanner._giscanner' > >This is fixed in 1.62.0-5 (#950267). Thanks, yes, that prevents the install of the "old" gobject-introspection with the new python3 from experimental. Regards, René -- Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.
Bug#949187: transition: python3.8
Hi, On Mon, Feb 03, 2020 at 08:24:50PM +0100, Matthias Klose wrote: > On 2/3/20 8:22 PM, Simon McVittie wrote: > > On Sun, 02 Feb 2020 at 09:35:04 +0100, Matthias Klose wrote: > >> I think this is now in shape to be started. > > > > Please can this wait until the remaining bits of the libffi7 transition > > and the restructuring of the libgcc_s packaging have settled down? > > > > I'm still trying to sort out the missing Breaks around > > gobject-introspection, as highlighted by autopkgtest failures: this has > > been delayed by needing coordinated action between multiple packages, > > some of them quite big (glib2.0), and by Paul and I being at FOSDEM. > > This is entangled with python3.8 via pygobject (which will fail tests > > with python3.8 as default - an upload is pending to fix that). > > fine. I'm happy to see that fixed. Yeah, gobject-introspection was actually what I meant when I wrote "fontforge". My bad, bad memory in a sid chroot with python 3.8 as default: root@frodo:/# python3 --version Python 3.8.1 root@frodo:/# g-ir-scanner Traceback (most recent call last): File "/usr/bin/g-ir-scanner", line 99, in from giscanner.scannermain import scanner_main File "/usr/lib/x86_64-linux-gnu/gobject-introspection/giscanner/scannermain.py", line 35, in from giscanner.ast import Include, Namespace File "/usr/lib/x86_64-linux-gnu/gobject-introspection/giscanner/ast.py", line 29, in from .sourcescanner import CTYPE_TYPEDEF, CSYMBOL_TYPE_TYPEDEF File "/usr/lib/x86_64-linux-gnu/gobject-introspection/giscanner/sourcescanner.py", line 33, in from giscanner._giscanner import SourceScanner as CSourceScanner ModuleNotFoundError: No module named 'giscanner._giscanner' and thus stuff building introspection will FTBFS (right now) (Thus I needed to disable it in my testbuild and thus libreoffice (1:6.4.0~beta1-4) experimental; urgency=medium * re-enable introspection which was accidentially kept disabled after a python3.8 test rebuild... * re-enable building of the "test packages" (-smoketest-data, -subsequentcheckbase) -- Rene Engelhard Sun, 15 Dec 2019 10:29:19 + happened.) Regards, Rene
Bug#949187: transition: python3.8
On Sun, Feb 02, 2020 at 06:12:08PM +0100, Rene Engelhard wrote: > Hi, > > On Sun, Feb 02, 2020 at 06:07:29PM +0100, Matthias Klose wrote: > > > e.g. fontforge is still red in > > > https://release.debian.org/transitions/html/python3.8.html. > > > > > > That means that a rebuild of stuff using fontforge in the build will > > > just FTBFS since it will be called with python3.8 and that has no module > > > for 3.8 (yet). > > > > > > (Seen in a python-3.8-as-default testbuild for libreoffice some time > > > ago.) > > > > you are wrong. fontforge just builds for the default python version. > > OK, maybe. But that also means that when python3.8 is default and > fontforge isn't yet rebuilt for python3.8-as-default but some package > from my list is rebuilt the same problem happens. OK; inded it seems to just work. Maybe I even misremembered an it was graphite2 and python3-fonttools. (Reused the chroot for multiple tests.) But I *had* a module import failure when I tried some months ago. Regards, Rene
Bug#949187: transition: python3.8
Hi, On Sun, Feb 02, 2020 at 06:07:29PM +0100, Matthias Klose wrote: > > e.g. fontforge is still red in > > https://release.debian.org/transitions/html/python3.8.html. > > > > That means that a rebuild of stuff using fontforge in the build will > > just FTBFS since it will be called with python3.8 and that has no module > > for 3.8 (yet). > > > > (Seen in a python-3.8-as-default testbuild for libreoffice some time > > ago.) > > you are wrong. fontforge just builds for the default python version. OK, maybe. But that also means that when python3.8 is default and fontforge isn't yet rebuilt for python3.8-as-default but some package from my list is rebuilt the same problem happens. Then fontforge (which is not in the list below!) needs to be rebuilt before https://release.debian.org/transitions/html/python3.8-default.html is worked on. Didn't see it there so wanted to go sure. Regards, Rene
Bug#949187: transition: python3.8
On Sun, Feb 02, 2020 at 05:53:37PM +0100, Rene Engelhard wrote: > On Sun, Feb 02, 2020 at 09:35:04AM +0100, Matthias Klose wrote: > > > On 17-01-2020 23:28, Matthias Klose wrote: > > >> Please add a transition tracker to switch the python3 default to 3.8. > > >> It's not > > >> yet ready, however it would be good to see affected packages. Please > > >> copy it > > >> from the 3.7 defaults change if possible. > > > > > > Tracker is in place. Please remove the moreinfo tag when you're ready. > > > > I think this is now in shape to be started. bug reports have been filed for > > I don't think so. > > e.g. fontforge is still red in > https://release.debian.org/transitions/html/python3.8.html. > > That means that a rebuild of stuff using fontforge in the build will > just FTBFS since it will be called with python3.8 and that has no module > for 3.8 (yet). $ grep-dctrl fontforge -FBuild-Depends /var/lib/apt/lists/deb.debian.org_debian_dists_unstable_main_source_Sources | grep-dctrl python3 -FBuild-Depends -sPackage Package: diffoscope Package: fonts-allerta Package: fonts-courier-prime Package: fonts-gotico-antiqua Package: fonts-junicode Package: fonts-karmilla Package: fonts-le-murmure Package: fonts-rit-sundar Package: fonts-smc-anjalioldlipi Package: fonts-smc-dyuthi Package: fonts-smc-karumbi Package: fonts-smc-keraleeyam Package: fonts-smc-meera Package: fonts-smc-rachana Package: fonts-smc-raghumalayalamsans Package: fonts-smc-uroob Package: fonts-solide-mirage Package: libreoffice Package: mftrace Package: searx Regards, Rene
Bug#949187: transition: python3.8
On Sun, Feb 02, 2020 at 09:35:04AM +0100, Matthias Klose wrote: > > On 17-01-2020 23:28, Matthias Klose wrote: > >> Please add a transition tracker to switch the python3 default to 3.8. > >> It's not > >> yet ready, however it would be good to see affected packages. Please copy > >> it > >> from the 3.7 defaults change if possible. > > > > Tracker is in place. Please remove the moreinfo tag when you're ready. > > I think this is now in shape to be started. bug reports have been filed for I don't think so. e.g. fontforge is still red in https://release.debian.org/transitions/html/python3.8.html. That means that a rebuild of stuff using fontforge in the build will just FTBFS since it will be called with python3.8 and that has no module for 3.8 (yet). (Seen in a python-3.8-as-default testbuild for libreoffice some time ago.) Regards, Rene
Bug#947397: transition: cppunit
On Wed, Jan 01, 2020 at 10:34:07PM +0100, Paul Gevers wrote: > Control: tags -1 - moreinfo > Control: tags -1 confirmed > > On 28-12-2019 11:21, Paul Gevers wrote: > > PS: @Rene, as gatb-core is a transition by itself, we'll proceed with > > cppunit after gatb-core migrates. > > Rene, please go ahead. It looks like gatb-core is now the only > reverse-dependency left. We'll handle it. OK, done. Regards, Rene
Bug#947397: transition: cppunit
On Wed, Jan 01, 2020 at 10:34:07PM +0100, Paul Gevers wrote: > Control: tags -1 - moreinfo > Control: tags -1 confirmed > > On 28-12-2019 11:21, Paul Gevers wrote: > > PS: @Rene, as gatb-core is a transition by itself, we'll proceed with > > cppunit after gatb-core migrates. > > Rene, please go ahead. It looks like gatb-core is now the only > reverse-dependency left. We'll handle it. But gab-core itself is blocked by the piuparts regression? $ grep-excuses gatb-core gatb-core (1.4.1+git20190813.a73b6dd+dfsg-1 to 1.4.1+git20191209.9398f28+dfsg-1) Maintainer: Debian Med Packaging Team 5 days old (needed 5 days) Migration status for gatb-core (1.4.1+git20190813.a73b6dd+dfsg-1 to 1.4.1+git20191209.9398f28+dfsg-1): BLOCKED: Rejected/violates migration policy/introduces a regression Issues preventing migration: Rejected due to piuparts regression - https://piuparts.debian.org/sid/source/g/gatb-core.html Additional info: 5 days old (needed 5 days) Regards, Rene
Bug#947397: transition: cppunit
Hi, On Fri, Dec 27, 2019 at 09:18:38PM +0100, Paul Gevers wrote: > > Most packages just build-depend on it. A rebuild using ratt just works, > > except some totally unrelated failures: > > I'm not able to reliably parse this sentence. Can you please elaborate a > bit more on what you mean here? # ratt -dist sid -sbuild_dist sid foo.changes 2019/12/25 19:27:13 Loading changes file "foo.changes" 2019/12/25 19:27:13 - 1 binary packages: 2019/12/25 19:27:13 Corresponding .debs (will be injected when building): 2019/12/25 19:27:13 dose-ceve(1) not found. Please install the dose-extra package for more accurate results. Falling back to interpreting Sources directly 2019/12/25 19:27:13 Loading sources index "/var/lib/apt/lists/deb.debian.org_debian_dists_unstable_main_source_Sources" 2019/12/25 19:27:14 Build results: root@frodo:/home/rene/Debian/Pakete/LibreOffice/cppunit# ratt -dist sid -sbuild_dist sid foo.changes 2019/12/25 19:27:32 Loading changes file "foo.changes" 2019/12/25 19:27:32 - 4 binary packages: libcppunit-1.15-0 libcppunit-1.15-0-dbgsym libcppunit-dev libcppunit-doc 2019/12/25 19:27:32 Corresponding .debs (will be injected when building): 2019/12/25 19:27:32 libcppunit-1.15-0_1.15.1-1_amd64.deb 2019/12/25 19:27:32 libcppunit-1.15-0-dbgsym_1.15.1-1_amd64.deb 2019/12/25 19:27:32 libcppunit-dev_1.15.1-1_amd64.deb 2019/12/25 19:27:32 libcppunit-doc_1.15.1-1_all.deb 2019/12/25 19:27:32 dose-ceve(1) not found. Please install the dose-extra package for more accurate results. Falling back to interpreting Sources directly 2019/12/25 19:27:32 Loading sources index "/var/lib/apt/lists/deb.debian.org_debian_dists_unstable_main_source_Sources" 2019/12/25 19:27:33 Building package 1 of 58: libqxp 2019/12/25 19:29:15 Building package 2 of 58: regina-normal 2019/12/25 19:30:54 building regina-normal failed: exit status 2 2019/12/25 19:30:54 Building package 3 of 58: sight 2019/12/25 20:02:24 Building package 4 of 58: squid 2019/12/25 20:10:32 Building package 5 of 58: orocos-bfl 2019/12/25 20:12:06 Building package 6 of 58: subunit 2019/12/25 20:13:10 Building package 7 of 58: gnuradio 2019/12/25 21:29:17 Building package 8 of 58: gr-gsm 2019/12/25 21:31:35 building gr-gsm failed: exit status 2 2019/12/25 21:31:35 Building package 9 of 58: libzmf 2019/12/25 21:32:57 Building package 10 of 58: schroot 2019/12/25 21:36:44 Building package 11 of 58: dymo-cups-drivers 2019/12/25 21:37:40 Building package 12 of 58: fw4spl 2019/12/25 21:37:56 building fw4spl failed: exit status 3 2019/12/25 21:37:56 Building package 13 of 58: libcmis 2019/12/25 21:42:52 Building package 14 of 58: gatb-core 2019/12/25 21:54:15 Building package 15 of 58: libfreehand 2019/12/25 21:55:18 Building package 16 of 58: nsis 2019/12/25 22:01:53 Building package 17 of 58: openvdb 2019/12/25 22:29:12 Building package 18 of 58: yapet 2019/12/25 22:32:42 Building package 19 of 58: aptitude 2019/12/25 22:43:25 Building package 20 of 58: genparse 2019/12/25 22:45:58 Building package 21 of 58: mapsembler2 2019/12/25 22:49:23 Building package 22 of 58: skstream 2019/12/25 22:50:03 Building package 23 of 58: zipios++ 2019/12/25 22:51:30 Building package 24 of 58: drumgizmo 2019/12/25 22:55:08 Building package 25 of 58: esys-particle 2019/12/25 22:58:00 building esys-particle failed: exit status 2 2019/12/25 22:58:00 Building package 26 of 58: ftgl 2019/12/25 23:00:02 Building package 27 of 58: libtorrent 2019/12/25 23:03:14 Building package 28 of 58: libwps 2019/12/25 23:06:37 Building package 29 of 58: megaglest 2019/12/26 05:43:54 Building package 30 of 58: ola 2019/12/26 05:52:19 building ola failed: exit status 2 2019/12/26 05:52:19 Building package 31 of 58: presage 2019/12/26 05:59:30 Building package 32 of 58: psocksxx 2019/12/26 06:00:52 Building package 33 of 58: siconos 2019/12/26 10:03:50 building siconos failed: exit status 2 2019/12/26 10:03:50 Building package 34 of 58: cwidget 2019/12/26 10:07:38 Building package 35 of 58: libfilezilla 2019/12/26 10:10:40 Building package 36 of 58: libdap 2019/12/26 10:19:02 Building package 37 of 58: librevenge 2019/12/26 10:21:28 Building package 38 of 58: libvisio 2019/12/26 10:24:31 Building package 39 of 58: rtorrent 2019/12/26 10:27:19 Building package 40 of 58: tagua 2019/12/26 10:31:26 Building package 41 of 58: ums2net 2019/12/26 10:32:05 Building package 42 of 58: cura-engine 2019/12/26 10:34:18 Building package 43 of 58: softhsm2 2019/12/26 10:40:32 Building package 44 of 58: cassiopee 2019/12/26 10:41:35 Building package 45 of 58: libepubgen 2019/12/26 10:43:44 Building package 46 of 58: libetonyek 2019/12/26 10:43:50 building libetonyek failed: exit status 3 2019/12/26 10:43:50 Building package 47 of 58: gr-iio 2019/12/26 10:45:35 building gr-iio failed: exit status 2 2019/12/26 10:45:35 Building package 48 of 58: jags 2019/12/26 10:51:41 Building package 49 of 58: libcdr 2019/12/26 10:53:21 Building package 50 of
Bug#947397: transition: cppunit
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Hi, Simple new (minor) upstream version. Most packages just build-depend on it. A rebuild using ratt just works, except some totally unrelated failures: gatb-core, libtorrent and rtorrent depend on the library package though for whatever reason and thus need to be bin-NMUed: # grep-dctrl -FDepends libcppunit-1.14-0 /var/lib/apt/lists/deb.debian.org_debian_dists_unstable_main_binary-amd64_Packages -sPackage [...] Package: gatb-core Package: libtorrent20 Package: rtorrent Ben file: title = "cppunit"; is_affected = .depends ~ "libcppunit-1.14-0" | .depends ~ "libcppunit-1.15-0"; is_good = .depends ~ "libcppunit-1.15-0"; is_bad = .depends ~ "libcppunit-1.14-0"; Regards, Rene -- System Information: Debian Release: 10.2 APT prefers stable APT policy: (990, 'stable'), (500, 'stable-updates') Architecture: arm64 (aarch64) Kernel: Linux 4.19.0-6-arm64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_CRAP Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Re: Processed: found 939940 in 0.5.1+git20160404-1, tagging 939940, found 939950 in 5.0.0.2456-1, tagging 939950 ...
Hi,
On Thu, Nov 21, 2019 at 05:09:49AM +0100, Andreas Beckmann wrote:
> >>> found 939956 0.6.2-1
> >> Bug #939956 {Done: Rene Engelhard } [src:liblangtag]
> >> liblangtag: fails to build with gtk-doc 1.32
> >> Marked as found in versions liblangtag/0.6.2-1.
>
> The bug did not have any "found" version, i.e. all versions smaller than
> the fixing 0.6.3-1 have this bug. While this is technically correct, it
> creates no or noisy version graphs in the BTS. As no versions older than
That is true, yes. I agree with that change.
> I'm also setting "relevant in sid and bullseye" (implying "not relevant
> in any release before stretch, stretch, buster, experimental" regardless
> what "found" and "fixed" say)
OK. But at the time of tagging it was not relevant for sid as 0.6.3-1
fixing this already was in the archive.
> PS: tagging "sid bullseye" where stable and testing have different
> versions is redundant since a "found" version would be sufficient.
Aha. Which will happen tomorrow anyway (normal 5 days waiting time),
so you say yourself the tagging wasn't needed but only the "found".
(As said above, the bug had a fixed version for 9 hours if I count right
already before the tagging)
Regards,
Rene
Re: Processed: found 939940 in 0.5.1+git20160404-1, tagging 939940, found 939950 in 5.0.0.2456-1, tagging 939950 ...
tag 939950 - sid
thanks
Hi,
On Wed, Nov 20, 2019 at 10:09:12PM +, Debian Bug Tracking System wrote:
> > found 939956 0.6.2-1
> Bug #939956 {Done: Rene Engelhard } [src:liblangtag]
> liblangtag: fails to build with gtk-doc 1.32
> Marked as found in versions liblangtag/0.6.2-1.
> > tags 939956 + sid bullseye
> Bug #939956 {Done: Rene Engelhard } [src:liblangtag]
> liblangtag: fails to build with gtk-doc 1.32
> Added tag(s) sid and bullseye.
Obviously not:
rene@frodo:~$ rmadison liblangtag
liblangtag | 0.5.1-3 | oldoldstable| source
liblangtag | 0.6.2-1 | oldstable | source
liblangtag | 0.6.2-1 | stable | source
liblangtag | 0.6.2-1 | testing | source
liblangtag | 0.6.3-1 | buildd-unstable | source
liblangtag | 0.6.3-1 | unstable| source
liblangtag | 0.6.3-1 | unstable-debug | source
Sid is *NOT* affected.
(and 0.6.3-1 fixed it.)
If you do stuff, do it correct.
Regards,
Rene
Bug#944002: buster-pu: package libreoffice/1:6.1.5-3+deb10u5
Hi, On Mon, Nov 04, 2019 at 08:23:58PM +, Adam D. Barratt wrote: > On Sat, 2019-11-02 at 15:41 +0100, Rene Engelhard wrote: > > I think we should fix #943873 in stable since even though stable has > > PostgreSQL 11 people might use it against some other server having > > 12... > > > > Please go ahead. Uploaded, thanks. Regards, Rene
Bug#944002: buster-pu: package libreoffice/1:6.1.5-3+deb10u5
Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu
Hi,
I think we should fix #943873 in stable since even though stable has
PostgreSQL 11 people might use it against some other server having
12...
Debdiff attached. (Patch from 1:6.3.3-2 cherry-picked.)
Regards,
Rene
diff --git a/changelog b/changelog
index d5983949..a78024d8 100644
--- a/changelog
+++ b/changelog
@@ -1,3 +1,11 @@
+libreoffice (1:6.1.5-3+deb10u5) buster; urgency=medium
+
+ * debian/patches/Postgresql-12-no-adsrc.diff: add from
+libreoffice-6-3 branch; fix the postgresql driver with
+PostgreSQL 12 (closes: #943873)
+
+ -- Rene Engelhard Thu, 31 Oct 2019 18:26:41 +0100
+
libreoffice (1:6.1.5-3+deb10u4) buster-security; urgency=medium
* debian/patches/expand-pyuno-path-separators.diff.
diff --git a/patches/Postgresql-12-no-adsrc.diff
b/patches/Postgresql-12-no-adsrc.diff
new file mode 100644
index ..76275ade
--- /dev/null
+++ b/patches/Postgresql-12-no-adsrc.diff
@@ -0,0 +1,128 @@
+From 0872f7dc87445f81afd56b5a096d026df75d3a05 Mon Sep 17 00:00:00 2001
+From: Julien Nabet
+Date: Sun, 13 Oct 2019 00:26:10 +0200
+Subject: tdf#128111: "adsrc" doesn't exist from Postgresql 12
+
+Before Postgresql 8.0, there was only "adsrc"
+then it's been deprecated
+"The adsrc field is historical, and is best not used, because it does not
track outside changes
+ that might affect the representation of the default value.
+ Reverse-compiling the adbin field (with pg_get_expr for example) is a better
way to display the default value
+"
+and finally it's been removed with version 12
+
+See evolution with:
+- https://www.postgresql.org/docs/8/catalog-pg-attrdef.html
+- https://www.postgresql.org/docs/11/catalog-pg-attrdef.html
+- https://www.postgresql.org/docs/12/catalog-pg-attrdef.html
+
+Merge with
https://cgit.freedesktop.org/libreoffice/core/commit/?id=1ec93ef100bb5f6ccef91f12e28ed09feb3eb38b
+
+Change-Id: I57e9da423a23b5a96bbb64b0e026b160e9643ab9
+Reviewed-on: https://gerrit.libreoffice.org/80722
+(cherry picked from commit 0c46c81e04530e8f6ce4f34195d8f0443ed8bfc3)
+Reviewed-on: https://gerrit.libreoffice.org/80736
+Tested-by: Jenkins
+Reviewed-by: Julien Nabet
+---
+ connectivity/source/drivers/postgresql/pq_databasemetadata.cxx | 6 +++---
+ connectivity/source/drivers/postgresql/pq_statement.cxx| 10 ++
+ connectivity/source/drivers/postgresql/pq_tools.cxx| 7 +++
+ connectivity/source/drivers/postgresql/pq_tools.hxx| 2 ++
+ 4 files changed, 18 insertions(+), 7 deletions(-)
+
+diff --git a/connectivity/source/drivers/postgresql/pq_databasemetadata.cxx
b/connectivity/source/drivers/postgresql/pq_databasemetadata.cxx
+index 10c8546..8af02f9 100644
+--- a/connectivity/source/drivers/postgresql/pq_databasemetadata.cxx
b/connectivity/source/drivers/postgresql/pq_databasemetadata.cxx
+@@ -1514,7 +1514,7 @@ css::uno::Reference< XResultSet >
DatabaseMetaData::getColumns(
+ //allow NULL values. An empty string means
+ //nobody knows.
+ // => pg_attribute.attnotnull
+-
++OUString strDefaultValue = getColExprForDefaultSettingVal(m_pSettings);
+ Reference< XPreparedStatement > statement = m_origin->prepareStatement(
+ "SELECT pg_namespace.nspname, " // 1
+ "pg_class.relname, " // 2
+@@ -1524,8 +1524,8 @@ css::uno::Reference< XResultSet >
DatabaseMetaData::getColumns(
+ "pg_attribute.attnotnull, " // 6
+ "pg_type.typdefault, " // 7
+ "pg_type.typtype, " // 8
+-"pg_attrdef.adsrc, " // 9
+-"pg_description.description, " // 10
+++ strDefaultValue + // 9
++",pg_description.description, " // 10
+ "pg_type.typbasetype, " // 11
+ "pg_attribute.attnum " // 12
+ "FROM pg_class, "
+diff --git a/connectivity/source/drivers/postgresql/pq_statement.cxx
b/connectivity/source/drivers/postgresql/pq_statement.cxx
+index 7796cac..79930e2 100644
+--- a/connectivity/source/drivers/postgresql/pq_statement.cxx
b/connectivity/source/drivers/postgresql/pq_statement.cxx
+@@ -631,10 +631,12 @@ static void getAutoValues(
+ String2StringMap & result,
+ const Reference< XConnection > & connection,
+ const OUString ,
+-const OUString & tableName )
++const OUString & tableName,
++ConnectionSettings *pConnectionSettings )
+ {
++OUString strDefaultValue =
getColExprForDefaultSettingVal(pConnectionSettings);
+ Reference< XPreparedStatement > stmt = connection->prepareStatement(
+-
Re: Bug#943401: libreoffice C++ Unit tests failing since gcc 9.2.1-12 ((Failure instantiating exceptionprotector)
reassign 935902 g++-9 affects 935902 libcppunit-dev found 935902 9.2.1-12 close 935902 9.2.1-16 thanks Hi, On Thu, Oct 31, 2019 at 03:15:10PM +0100, Matthias Klose wrote: > The comment about cppunit made me look at the cppunit package to find > #935902, and yes, the test case is reproducible. So looking at the test Ah, that one... Reassigning to gcc (and marking as fixed) > failure would have been revealed that the test frame work is broken, not a > single test. This turned out to be https://gcc.gnu.org/PR92267, causing an > ABI breakage in cppunit. OK. > The fix is now in -16. Good. Can confirm. You can close the bug. Regards, Rene
Re: Bug#943401: libreoffice C++ Unit tests failing since gcc 9.2.1-12 ((Failure instantiating exceptionprotector)
Hi, Am 31. Oktober 2019 15:15:10 MEZ schrieb Matthias Klose : >And afaik there was no test rebuild for >bullseye >either. Accepted cppunit 1.14.0-4 (source) into unstable On July 26: https://tracker.debian.org/news/1049803/accepted-cppunit-1140-4-source-into-unstable/ Buster release was 3 weeks before that. So this "no test rebuild for bullseye" is not true. Regards Rene -- Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.
Re: Bug#943401: libreoffice C++ Unit tests failing since gcc 9.2.1-12 ((Failure instantiating exceptionprotector)
Hi, Am 31. Oktober 2019 15:15:10 MEZ schrieb Matthias Klose : >On 29.10.19 15:09, Vincent Lefevre wrote: >> On 2019-10-29 13:09:46 +0100, rene.engelh...@mailbox.org wrote: >>> Am 29. Oktober 2019 12:49:44 MEZ schrieb Vincent Lefevre >: In case makefile magic triggers some rebuild, you can also run the generated executable directly (with the right environment >variables, in case this matters). If the programs honors the system ABI, this is allowed, and you'll effectively test the new libstdc++6. >>> >>> No, if the rebuild rebuilds cppunittester or one of the >>> exceptionprotectors or the smoketest so or similar we are at the >>> same situation as with the autopkgtest (that's what it builds) and >>> are not sure whether it's g++-9 or libstdc++6. Neither LO nor the >>> test are an executable it's a executable with gazillions of .sos. >> >> I meant running the generated program (smoketest) without rebuilding >> it: >> >> 1. Build smoketest with the old g++-9 / libstdc++6. >> 2. Upgrade g++-9 / libstdc++6. >> 3. Run smoketest directly. >> >> (I assume that the smoketest executable does not invoke g++-9 to >> rebuild things on the fly.) > >I'm not sure if Rene wants to help tracking this down, he just disabled >running >the test in >https://salsa.debian.org/libreoffice-team/libreoffice/libreoffice/commit/99764f8d0df2f40aba9a220a8a4858d3f6d05494 *temporarily* >and introducing a typo in >https://salsa.debian.org/libreoffice-team/libreoffice/libreoffice/commit/998c3b1c63bbedf8d886227749279d7ccb26a30b >So maybe don't commit if you are angry. > Maybe, yes, but I needed to get it builds le got the upload. Will fix, thanks. ><_rene_> how supported is clang on the various (release) archs? ><_rene_> completely? ><_rene_> (clang++ if it matters) ><_rene_> (actually probably only matters for amd64/arm64 for now, >but...) > >so I assume we cannot expect Rene's help for that issue anymore. Unfortunately the tests fail when LO is built with clang. So yes, we need to track it down. >The comment about cppunit made me look at the cppunit package to find >#935902, >and yes, the test case is reproducible. So looking at the test failure >would >have been revealed that the test frame work is broken, not a single >test. I said in some comment that "the first" test failed: basic_scanner. I didn't say smoketest was the only one. It's the only one done in autopkgtest though. This >turned out to be https://gcc.gnu.org/PR92267, causing an ABI breakage >in >cppunit. The fix is now in -16. Ok. Will try. Then I can add build-conflcts or so and reenable the tests. >So a symbols file and a test rebuild should have at least flagged >something, however cppunit doesn't have symbols files, because the >package >maintainer doesn't like them. For C++ and the mangling and handling it in all arxgs, yes. > And afaik there was no test rebuild for bullseye >l either. It does not help to blame people for not doing a rebuild when there is no rebuild necessary. Regards Rene -- Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.
libreoffice C++ Unit tests failing when built with gcc >= 9.2.1-12 (Failure instantiating exceptionprotector) (was: Re: Bug#943401: libreoffice C++ Unit tests failing since gcc) 9.2.1-12 ((Failure ins
reassign 943401 gcc-9
found 943401 9.2.1-12
retitle 943401 libreoffice C++ Unit tests failing when built with gcc >=
9.2.1-12 (Failure instantiating exceptionprotector)
thanks
On Tue, Oct 29, 2019 at 03:09:50PM +0100, Vincent Lefevre wrote:
> 1. Build smoketest with the old g++-9 / libstdc++6.
In testing against 6.3.2 there:
== Starting smoketest with 1 job against
path:/usr/lib/libreoffice/program/soffice ==
S=/home/rene/Debian/Pakete/LibreOffice/libreoffice/libreoffice-6.3.2.2 &&
I=/usr/lib/libreoffice && W=$S/workdir && touch
$W/Headers/CppunitTest/libtest_smoketest.so
[CXX] smoketest/smoketest_too.cxx
S=/home/rene/Debian/Pakete/LibreOffice/libreoffice/libreoffice-6.3.2.2 &&
I=/usr/lib/libreoffice && W=$S/workdir && mkdir -p $W/CxxObject/smoketest/
$W/Dep/CxxObject/smoketest/ && cd
/home/rene/Debian/Pakete/LibreOffice/libreoffice/libreoffice-6.3.2.2 &&
x86_64-linux-gnu-g++ -DBOOST_ERROR_CODE_HEADER_ONLY
-DBOOST_SYSTEM_NO_DEPRECATED -DCPPU_ENV=gcc3 -DLINUX -DNDEBUG
-DOSL_DEBUG_LEVEL=0 -DUNIX -DUNX -DX86_64 -D_FORTIFY_SOURCE=2 -D_PTHREADS
-D_REENTRANT -Wdate-time -DCPPUNIT_PLUGIN_EXPORT='extern "C"
SAL_DLLPUBLIC_EXPORT' -fvisibility=hidden-Wall -Wno-missing-braces
-Wnon-virtual-dtor -Wendif-labels -Wextra -Wundef -Wunreachable-code
-Wunused-macros -finput-charset=UTF-8 -fmessage-length=0 -fno-common -pipe
-Wno-maybe-uninitialized -Wduplicated-cond -Wlogical-op -Wshift-overflow=2
-Wunused-const-variable=1 -Wno-cast-function-type -fvisibility-inlines-hidden
-fPIC -Wshadow -Woverloaded-virtual -std=gnu++2a -pthread -DEXCEPTIONS_ON
-fexceptions -fno-enforce-eh-specs -g -O2
-fdebug-prefix-map=/home/rene/Debian/Pakete/LibreOffice/libreoffice/libreoffice-6.3.2.2=.
-fstack-protector-strong -Wformat -Werror=format-security
-DLIBO_INTERNAL_ONLY -c $S/smoketest/smoketest_too.cxx -o
$W/CxxObject/smoketest/smoketest_too.o -I$S/include
-I/usr/lib/jvm/default-java/include -I/usr/lib/jvm/default-java/include/linux
-I$S/config_host -I/usr/include -I$W/UnoApiHeadersTarget/udkapi/normal
-I$W/UnoApiHeadersTarget/offapi/normal
[LNK] CppunitTest/libtest_smoketest.so
S=/home/rene/Debian/Pakete/LibreOffice/libreoffice/libreoffice-6.3.2.2 &&
I=/usr/lib/libreoffice && W=$S/workdir && x86_64-linux-gnu-g++ -pthread
-shared -Wl,-z,noexecstack -Wl,-z,origin '-Wl,-rpath,$ORIGIN/../Library'
-Wl,-rpath-link,$I/program -Wl,-z,defs -Wl,-rpath-link,/lib:/usr/lib
-Wl,-z,combreloc -Wl,--hash-style=gnu -Wl,-Bsymbolic-functions
-L$W/LinkTarget/StaticLibrary -L$I/sdk/lib -L$S/instdir/program
-L$S/instdir/program -L$W/LinkTarget/Library -Wl,-z,relro
$W/CxxObject/smoketest/smoketest_too.o -Wl,--start-group-lcppunit
-Wl,--end-group -Wl,--no-as-needed -luno_cppu -luno_cppuhelpergcc3 -luno_sal
-lunotest -o $W/LinkTarget/CppunitTest/libtest_smoketest.so
TEMPFILE=/tmp/gbuild.ptBn7D && mv ${TEMPFILE}
/home/rene/Debian/Pakete/LibreOffice/libreoffice/libreoffice-6.3.2.2/workdir/LinkTarget/CppunitTest/libtest_smoketest.so.objectlist
rm -rf
/home/rene/Debian/Pakete/LibreOffice/libreoffice/libreoffice-6.3.2.2/workdir/CustomTarget/smoketest
mkdir -p
/home/rene/Debian/Pakete/LibreOffice/libreoffice/libreoffice-6.3.2.2/workdir/CustomTarget/smoketest/user
cp
/home/rene/Debian/Pakete/LibreOffice/libreoffice/libreoffice-6.3.2.2/qadevOOo/qa/registrymodifications.xcu
/home/rene/Debian/Pakete/LibreOffice/libreoffice/libreoffice-6.3.2.2/workdir/CustomTarget/smoketest/user
mkdir -p
/home/rene/Debian/Pakete/LibreOffice/libreoffice/libreoffice-6.3.2.2/workdir/Zip/
touch
/home/rene/Debian/Pakete/LibreOffice/libreoffice/libreoffice-6.3.2.2/workdir/Zip/smoketestdoc.prepare
[ZIP] smoketestdoc
S=/home/rene/Debian/Pakete/LibreOffice/libreoffice/libreoffice-6.3.2.2 &&
I=/usr/lib/libreoffice && W=$S/workdir && RESPONSEFILE=/tmp/gbuild.jGkR3E &&
cd $S/smoketest/data && cat ${RESPONSEFILE} | tr "[:space:]" "\n" | zip -D
-@rX --filesync --must-match $W/Zip/smoketestdoc.zip && rm -f ${RESPONSEFILE}
&& touch $W/Zip/smoketestdoc.zip
adding: mimetype (stored 0%)
adding: content.xml (deflated 77%)
adding: meta.xml (deflated 55%)
adding: settings.xml (deflated 80%)
adding: styles.xml (deflated 77%)
adding: META-INF/manifest.xml (deflated 73%)
adding: Basic/script-lc.xml (deflated 47%)
adding: Basic/Standard/script-lb.xml (deflated 52%)
adding: Basic/Standard/Events.xml (deflated 54%)
adding: Basic/Standard/Global.xml (deflated 78%)
adding: Basic/Standard/Test_10er.xml (deflated 80%)
adding: Basic/Standard/Test_DB.xml (deflated 68%)
adding: Basic/Standard/Test_Ext.xml (deflated 47%)
adding: Dialogs/dialog-lc.xml (deflated 47%)
adding: Dialogs/Standard/dialog-lb.xml (deflated 47%)
adding: Dialogs/Standard/OptionsDlg.xml (deflated 73%)
cp
/home/rene/Debian/Pakete/LibreOffice/libreoffice/libreoffice-6.3.2.2/workdir/Zip/smoketestdoc.zip
/home/rene/Debian/Pakete/LibreOffice/libreoffice/libreoffice-6.3.2.2/workdir/Zip/smoketestdoc.sxw
[CUT]
Re: Bug#943401: libreoffice C++ Unit tests failing since gcc 9.2.1-12 ((Failure instantiating exceptionprotector)
Hi, Am 29. Oktober 2019 15:09:50 MEZ schrieb Vincent Lefevre : >On 2019-10-29 13:09:46 +0100, rene.engelh...@mailbox.org wrote: >> Am 29. Oktober 2019 12:49:44 MEZ schrieb Vincent Lefevre >: >> >In case makefile magic triggers some rebuild, you can also run the >> >generated executable directly (with the right environment variables, >> >in case this matters). If the programs honors the system ABI, this >> >is allowed, and you'll effectively test the new libstdc++6. >> >> No, if the rebuild rebuilds cppunittester or one of the >> exceptionprotectors or the smoketest so or similar we are at the >> same situation as with the autopkgtest (that's what it builds) and >> are not sure whether it's g++-9 or libstdc++6. Neither LO nor the >> test are an executable it's a executable with gazillions of .sos. > >I meant running the generated program (smoketest) without rebuilding >it: Smoketest is not a program but also a libsmoketest.so "ran" by cppunittester. >1. Build smoketest with the old g++-9 / libstdc++6. >2. Upgrade g++-9 / libstdc++6. >3. Run smoketest directly. That would need to copy the longish command from the old log, but yeah. >(I assume that the smoketest executable does not invoke g++-9 to >rebuild things on the fly.) No, but make check in smokest might rebuild stuff. That was what I was aiming at. This already happens in "normal" builds. Regards Rene -- Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.
Re: Bug#943401: libreoffice C++ Unit tests failing since gcc 9.2.1-12 ((Failure instantiating exceptionprotector)
Hi, Am 29. Oktober 2019 12:49:44 MEZ schrieb Vincent Lefevre : >In case makefile magic triggers some rebuild, you can also run the >generated executable directly (with the right environment variables, >in case this matters). If the programs honors the system ABI, this >is allowed, and you'll effectively test the new libstdc++6. No, if the rebuild rebuilds cppunittester or one of the exceptionprotectors or the smoketest so or similar we are at the same situation as with the autopkgtest (that's what it builds) and are not sure whether it's g++-9 or libstdc++6. Neither LO nor the test are an executable it's a executable with gazillions of .sos. Regards Rene -- Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.
Re: Bug#943401: libreoffice C++ Unit tests failing since gcc 9.2.1-12 ((Failure instantiating exceptionprotector)
Hi again, Am 29. Oktober 2019 11:26:41 MEZ schrieb rene.engelh...@mailbox.org: >Hi, > >Am 29. Oktober 2019 10:59:07 MEZ schrieb Vincent Lefevre >: >> If you build LO >>with an older gcc-9 version, upgrade libstdc++6, and run the test >>again (without rebuilding it), does it fail? > >This is impossible. This is a C++ unit test and the stuff assumes too >much of the build tree. You need to actually build the test libs etc to >run it. > >That is why autopkgtest does only smoketest [...] Well, thinking about it it might be possible. Build on testing, debian/tests/smoketest, dist-upgrade to did and rerun it and hope some makefile magic doesn't trigger some rebuild... The smokest (except the cppunit blurb) just does "run lo, open smoketestdoc.sxw, run some macros to test basic stuff". Will try... Regards Rene -- Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.
Re: Bug#943401: libreoffice C++ Unit tests failing since gcc 9.2.1-12 ((Failure instantiating exceptionprotector)
Hi, Am 29. Oktober 2019 10:59:07 MEZ schrieb Vincent Lefevre : > If you build LO >with an older gcc-9 version, upgrade libstdc++6, and run the test >again (without rebuilding it), does it fail? This is impossible. This is a C++ unit test and the stuff assumes too much of the build tree. You need to actually build the test libs etc to run it. That is why autopkgtest does only smoketest instead of all c++ unit tests even though the latter would be helpful. Tried to decouple it once but failed as it always either wanted something present it write in the "instdir". Regards Rene -- Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.
Re: libreoffice C++ Unit tests failing since gcc 9.2.1-12 ((Failure instantiating exceptionprotector)
Hi, On Mon, Oct 28, 2019 at 10:39:37PM +0100, Matthias Klose wrote: > > but let's try to work together to fix the current situation. That's what I tried, but... Disabling make check (as will be done) is not "fix"ing but just hiding it. > my moreinfo tag was removed, and I'm not interested in a bts war, which rene > likes to start very often. and, no, I won't start citing rene's private > messages here. You imply they were bad. I can cite them myself if you want. There wasn't bad messages, it was basically the same which was in the bug but in german. You like to make other people bad where this is not the case. In this case this is not a LO bug since the exact same LO version worked until said gcc upload. Regards, Rene
Re: libreoffice C++ Unit tests failing since gcc 9.2.1-12 ((Failure instantiating exceptionprotector)
Hi, On Mon, Oct 28, 2019 at 10:39:37PM +0100, Matthias Klose wrote: > On 28.10.19 22:17, Paul Gevers wrote: > > Dear all, > > > > The visible progress on this bug report stopped several days ago. I'd > > like to try an get it a bit further. I'm expecting frustration on all > > sides, > > yes, and side note that I will use the same terms of "several days ago" for > a three day silence including two non-work days. > > > but let's try to work together to fix the current situation. > > my moreinfo tag was removed, and I'm not interested in a bts war, which rene Because you got the needed info. "Run debian/tests/smoketest". I don't have more info, and simply don't have time or knowledge on C++ exceptions to handle this either way. > likes to start very often. and, no, I won't start citing rene's private *You* reassigned the bug back with "with what rationale" and failed to read the bug log that I mentioned the gcc upload and the exception failure and still insisted on Dmitrys dates in the subject which I said to be non-true in the first message of the bug. You started the BTS war, not me. If you read the bug you could have just kept it at gcc without any BTS war. > > Matthias, did you have time to look into the issue? Have you discovered > > anything that is worth knowing already? If not, do you intent to work on > > this soon. I noticed you uploaded a new version that doesn't address > > this RC bug, for the reason I mentioned above, could you please refrain > > from uploading new versions unless critical issues that aren't present > > in testing are fixed in those uploads until a version of gcc-9 migrates? > > I asked for a test case, not a multi-hour build and a multi-hour test run. And I said it exceeds my knowledge. debian/tests/smoketest is not a "multi hour test run". It builds part of LO, yes, but it definitely is not multi hour. It is actually ONE test. See the script. The autopktest actually times itself out when it takes too long (which doesn't happen even on older hardware.) > Sure I can start looking at this myself, but I don't have the LO domain > knowledge anymore. Yes, I could start bisecting, however that doesn't sound Neither do I. I just maintain and build this. Let alone time-wise... Regards. Rene
Re: libreoffice C++ Unit tests failing since gcc 9.2.1-12 ((Failure instantiating exceptionprotector)
Hi, On Mon, Oct 28, 2019 at 10:17:49PM +0100, Paul Gevers wrote: > Rene, I really appreciate the fact that libreoffice has an extensive > test suite. But just to get options on the table can you please tell us > how severe this particular failure is? In other words, how much is this > telling you about libreoffice? I think the failure is "just" that you No idea. The test doesn't run. No more info. And the failure is beyond my skills anyway. > can't compile a test that used to be able to compile. And you suspect > that the libreoffice test may not be the only code that breaks. No, I didn't say that. Actually, I disabled running make check already for the next upload. "at scheduled" for Thursday. Regards, Rene
