Hi,
Am 04.02.23 um 18:30 schrieb Soren Stoutner:
I have submitted a merge request to the qt6webengine package that
implements what has been discussed.
https://salsa.debian.org/qt-kde-team/qt6/qt6-webengine/-/merge_requests/4
Once it is merged, I will prepare a merge request for the
tag 1031199 + moreinfo
thanks
Hi,
Am 13. Februar 2023 07:12:24 MEZ schrieb Mato :
>Package: liblangtag-common
>Version: 0.6.4-2
(...)
>Last update
You mean the one in August last year?
> introduced timezone error, where Bratislava is in wrong
>timezone now. tzdata package is correct. It
tag 1031199 + moreinfo
thanks
Hi,
Am 13. Februar 2023 07:12:24 MEZ schrieb Mato :
>Package: liblangtag-common
>Version: 0.6.4-2
(...)
>Last update
You mean the one in August last year?
> introduced timezone error, where Bratislava is in wrong
>timezone now. tzdata package is correct. It
Hi,
Am 04.02.23 um 19:14 schrieb Soren Stoutner:
Seeing as how .bdic files are not exclusive to Qt, qt-convert-dict is probably
not the most accurate name, but bdic-convert-dict would make sense. Another
option would be to name it convert-bdic. The Chromium upstream names the tool
Hi,
Am 04.02.23 um 18:30 schrieb Soren Stoutner:
I have submitted a merge request to the qt6webengine package that
implements what has been discussed.
https://salsa.debian.org/qt-kde-team/qt6/qt6-webengine/-/merge_requests/4
Once it is merged, I will prepare a merge request for the
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
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
Hi,
Am 24.01.23 um 07:24 schrieb Susmita/Rajib:
However, the values in the sub-menus under the Libre Office / Options
/ Language Settings / Writing Aids / Available language modules, can't
be changed from English (USA) to English (UK), particularly for the
sub-menus as shown in the said
Control: tag -1 pending
Hello,
Bug #1029534 in libreoffice reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:
Control: tag -1 pending
Hello,
Bug #1029534 in libreoffice reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:
configure.ac |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
New commits:
commit bd805279bfa1e952fdc8e4de6014ffda8cfdc29c
Author: Rene Engelhard
AuthorDate: Sun Jan 22 11:58:41 2023 +0100
Commit: Christian Lohmaier
CommitDate: Wed Jan 25 13:54:56 2023 +
check
configure.ac |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
New commits:
commit 07c49eeaee97fbe084205ea2b52e3b4f4b1c4173
Author: Rene Engelhard
AuthorDate: Sun Jan 22 20:53:35 2023 +0100
Commit: Caolán McNamara
CommitDate: Tue Jan 24 08:51:00 2023 +
update hardcoded
Hi,
Am 23.01.23 um 23:04 schrieb Sven Joachim:
The Breaks in libreoffice-common need to be adjusted for the recent
epoch bumps. Among others, libreoffice-common Breaks
libreoffice-core (>= 1:7.5~), making libreoffice-core 4:7.4.4-7
not installable.
Yeah, that one I noticed yesterday already.
Hi,
Am 23.01.23 um 23:04 schrieb Sven Joachim:
The Breaks in libreoffice-common need to be adjusted for the recent
epoch bumps. Among others, libreoffice-common Breaks
libreoffice-core (>= 1:7.5~), making libreoffice-core 4:7.4.4-7
not installable.
Yeah, that one I noticed yesterday already.
Hi,
Am 23.01.23 um 23:04 schrieb Sven Joachim:
The Breaks in libreoffice-common need to be adjusted for the recent
epoch bumps. Among others, libreoffice-common Breaks
libreoffice-core (>= 1:7.5~), making libreoffice-core 4:7.4.4-7
not installable.
Yeah, that one I noticed yesterday already.
configure.ac |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
New commits:
commit f8604f08ed5e07e50a65b5d35f3c0c18bf19044a
Author: Rene Engelhard
AuthorDate: Sun Jan 22 20:53:35 2023 +0100
Commit: René Engelhard
CommitDate: Mon Jan 23 18:22:08 2023 +
update hardcoded
/source/rtftok/rtfdocumentimpl.cxx | 17
writerfilter/source/rtftok/rtfdocumentimpl.hxx |3
97 files changed, 1446 insertions(+), 246 deletions(-)
New commits:
commit 339b90e9a1c89f8e67aeee94d06878b4e130ac36
Author: Rene Engelhard
AuthorDate: Sun Jan 22 11
configure.ac |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
New commits:
commit 76742388b3dcfe69d8af33137bc51135e58fbfa0
Author: Rene Engelhard
AuthorDate: Sun Jan 22 11:58:41 2023 +0100
Commit: René Engelhard
CommitDate: Sun Jan 22 11:16:54 2023 +
check for harfbuzz
configure.ac |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
New commits:
commit a180a99e2d53a2ca04e8fe31a38f6994e42bf69b
Author: Rene Engelhard
AuthorDate: Sun Jan 22 11:58:41 2023 +0100
Commit: René Engelhard
CommitDate: Sun Jan 22 11:12:01 2023 +
check for harfbuzz
Hi,
Am 21.01.23 um 20:36 schrieb Fabian Greffrath:
Am Samstag, dem 21.01.2023 um 18:55 +0100 schrieb Rene Engelhard:
This upgrade, which now unfortunately already is in testing makes the
font NOT metric-compatible with Cambria...
Ouch, that's unfortunate! Do we know which glyphs are affected
Hi,
also note that this bug is (probably, just test-building with the
mentioned LibreOffice commit the cause of this FTBFS:
https://buildd.debian.org/status/fetch.php?pkg=libreoffice=amd64=1%3A7.5.0%7Erc2-2=1674319650=0
Thankfully it seems to only break the 7.5+ test, not 7.4.4 in sid.
Package: fonts-crosextra-caladea
Severity: important
Version: 20200211-1
Tags: upstream
Forwarded: https://github.com/huertatipografica/Caladea/issues/4
Hi,
>From https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1028459 :
Am Wed, Jan 11, 2023 at 10:46:04AM + schrieb Amr Ibrahim:
>
>
Hi,
Am 19.01.23 um 12:46 schrieb Andreas Henriksson:
I'd like to explicitly ask if you still want me to upload any
fontconfig change ASAP or if downgrading severity means you think
it can/should wait until after release?
worked around it in libreoffice for now, so your decision in the end.
Control: tag -1 pending
Hello,
Bug #1029104 in libreoffice reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:
Control: tag -1 pending
Hello,
Bug #1029104 in libreoffice reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:
Control: tag -1 pending
Hello,
Bug #1029104 in libreoffice reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:
severity 1029101 important
retitle 1029101 please Enable RGB stripes layout for sub-pixel rendering
on KDE only
thanks
[ sorry for "spamming" ]
Hi,
Am 17.01.23 um 19:04 schrieb Rene Engelhard:
it still fails. Probably it ignores it since it's already set in /etc
and that alrea
severity 1029101 important
retitle 1029101 please Enable RGB stripes layout for sub-pixel rendering
on KDE only
thanks
[ sorry for "spamming" ]
Hi,
Am 17.01.23 um 19:04 schrieb Rene Engelhard:
it still fails. Probably it ignores it since it's already set in /etc
and that alrea
Hi again,
Am 17.01.23 um 18:28 schrieb Rene Engelhard:
I tried to adapt the test to expected values but failed. When I adapt
some values stuff even further breaks, and at the 50% test I then had no
idea what to do.)
LO has already a fc_local.conf:
./instdir/share/fonts/truetype
Hi again,
Am 17.01.23 um 18:28 schrieb Rene Engelhard:
I tried to adapt the test to expected values but failed. When I adapt
some values stuff even further breaks, and at the 50% test I then had no
idea what to do.)
LO has already a fc_local.conf:
./instdir/share/fonts/truetype
Hi,
addendum:
I tried to adapt the test to expected values but failed. When I adapt
some values stuff even further breaks, and at the 50% test I then had no
idea what to do.)
For reference, this is the test:
Hi,
addendum:
I tried to adapt the test to expected values but failed. When I adapt
some values stuff even further breaks, and at the 50% test I then had no
idea what to do.)
For reference, this is the test:
Package: fontconfig-config
Version: 2.14.1-3
Severity: serious
Justification: causes FTBFS
Tags: patch
Dear Maintainer,
See
https://buildd.debian.org/status/fetch.php?pkg=libreoffice=amd64=1%3A7.4.4-1=1673962775=0:
[_RUN_] VclTextTest::testSimpleText
Package: fontconfig-config
Version: 2.14.1-3
Severity: serious
Justification: causes FTBFS
Tags: patch
Dear Maintainer,
See
https://buildd.debian.org/status/fetch.php?pkg=libreoffice=amd64=1%3A7.4.4-1=1673962775=0:
[_RUN_] VclTextTest::testSimpleText
Hi,
Am 12.01.23 um 09:29 schrieb Gábor Németh:
make[1]: *** No rule to make target
'/lo/external/tarballs/boost_1_79_0.tar.xz', needed by
'/lo/workdir/UnpackedTarget/boost_1_79_0.tar.xz'. Stop.
Hm, so Boost is not mentioned in the deps? OK, repeat with:
Not mentioned because it's the internal
Hi,
Am 12.01.23 um 09:29 schrieb Gábor Németh:
make[1]: *** No rule to make target
'/lo/external/tarballs/boost_1_79_0.tar.xz', needed by
'/lo/workdir/UnpackedTarget/boost_1_79_0.tar.xz'. Stop.
Hm, so Boost is not mentioned in the deps? OK, repeat with:
Not mentioned because it's the internal
Hi,
Am 11.01.23 um 19:54 schrieb Gregor Riepl:
On the KDE question - does LO really depend on KDE?
Isn't there also Gnome support?
Yes. *also*.
Which means that it builds both and thus build-depends on both (and it
ends up in libreoffice-gtk3, libreoffice-qt5, libreoffice-kf5 of what
the
Hi,
Am 11.01.23 um 19:08 schrieb John Paul Adrian Glaubitz:
You may argue that it's okay because it works on x86_64. However, it
only works because Intel
didn't make use of the upper 16 bits of a 64-bit pointer in the past
although these were always
reserved. But that has changed now with the
Hi,
Am 11.01.23 um 15:20 schrieb John Paul Adrian Glaubitz:
Hi Helge!
On 1/11/23 15:03, Helge Deller wrote:
Yes, sadly we don't have a working java right now on hppa, and it will
probably take some more time to get one. At least I won't have time
for it during the next few months.
But it
Hi,
Am 11.01.23 um 12:41 schrieb Gregor Riepl:
- sparc and sparc64
(which are for many BD-Uninstallable since ages because it does not
have Java (anymore), didn't do a long-ago transition, ...)
[...]
Looking at
https://buildd.debian.org/status/package.php?p=libreoffice#problem-17
, it
Hi,
Am 10.01.23 um 20:30 schrieb John Paul Adrian Glaubitz:
I just noticed that debian/rules adds the powerpc architecture to the UBSAN_ARCH
arch list despite powerpc not supporting `__sync_val_compare_and_swap_8 [1].
But libubsan.so exists, which was what was intended with this variable...
Hi,
Am 10.01.23 um 19:44 schrieb John Paul Adrian Glaubitz:
On 1/10/23 19:25, Rene Engelhard wrote:
(which are for many BD-Uninstallable since ages because it does not
have Java (anymore), didn't do a long-ago transition, ...)
They all have Java support except for hppa, see:
I was indeed
Hi,
Am 10.01.23 um 14:43 schrieb Andreas Tille:
Since the test to replace the dictionaries shipped with upstream
source by the Debian packaged version results in two test suite
issues I'm tagging this bug wontfix.
I don't buy the reasoning. Then whatever needs to be adapted needs to be
Hi,
Am 10.01.23 um 17:31 schrieb Stephan Bergmann:
Next, there are 2 additional implementations that I know are built for
Fedora releases; they go into category 2.
Also in Debian
Next, there are 2 additional implementations that I presume are built
for Debian releases (Rene, correct me if
C++ UNO bridge implementations
(bridges/source/cpp_uno/*)
Datum: Tue, 10 Jan 2023 17:31:12 +0100
Von:Stephan Bergmann
An: libreoff...@lists.freedesktop.org
Kopie (CC): Sakura286 , wjh-la
, Rene Engelhard , Tor Lillqvist
There are currently 27 different, per-platform C++ UNO
C++ UNO bridge implementations
(bridges/source/cpp_uno/*)
Datum: Tue, 10 Jan 2023 17:31:12 +0100
Von:Stephan Bergmann
An: libreoff...@lists.freedesktop.org
Kopie (CC): Sakura286 , wjh-la
, Rene Engelhard , Tor Lillqvist
There are currently 27 different, per-platform C++ UNO
C++ UNO bridge implementations
(bridges/source/cpp_uno/*)
Datum: Tue, 10 Jan 2023 17:31:12 +0100
Von:Stephan Bergmann
An: libreoff...@lists.freedesktop.org
Kopie (CC): Sakura286 , wjh-la
, Rene Engelhard , Tor Lillqvist
There are currently 27 different, per-platform C++ UNO
C++ UNO bridge implementations
(bridges/source/cpp_uno/*)
Datum: Tue, 10 Jan 2023 17:31:12 +0100
Von:Stephan Bergmann
An: libreoff...@lists.freedesktop.org
Kopie (CC): Sakura286 , wjh-la
, Rene Engelhard , Tor Lillqvist
There are currently 27 different, per-platform C++ UNO
C++ UNO bridge implementations
(bridges/source/cpp_uno/*)
Datum: Tue, 10 Jan 2023 17:31:12 +0100
Von:Stephan Bergmann
An: libreoff...@lists.freedesktop.org
Kopie (CC): Sakura286 , wjh-la
, Rene Engelhard , Tor Lillqvist
There are currently 27 different, per-platform C++ UNO
C++ UNO bridge implementations
(bridges/source/cpp_uno/*)
Datum: Tue, 10 Jan 2023 17:31:12 +0100
Von:Stephan Bergmann
An: libreoff...@lists.freedesktop.org
Kopie (CC): Sakura286 , wjh-la
, Rene Engelhard , Tor Lillqvist
There are currently 27 different, per-platform C++ UNO
C++ UNO bridge implementations
(bridges/source/cpp_uno/*)
Datum: Tue, 10 Jan 2023 17:31:12 +0100
Von:Stephan Bergmann
An: libreoff...@lists.freedesktop.org
Kopie (CC): Sakura286 , wjh-la
, Rene Engelhard , Tor Lillqvist
There are currently 27 different, per-platform C++ UNO
C++ UNO bridge implementations
(bridges/source/cpp_uno/*)
Datum: Tue, 10 Jan 2023 17:31:12 +0100
Von:Stephan Bergmann
An: libreoff...@lists.freedesktop.org
Kopie (CC): Sakura286 , wjh-la
, Rene Engelhard , Tor Lillqvist
There are currently 27 different, per-platform C++ UNO
C++ UNO bridge implementations
(bridges/source/cpp_uno/*)
Datum: Tue, 10 Jan 2023 17:31:12 +0100
Von:Stephan Bergmann
An: libreoff...@lists.freedesktop.org
Kopie (CC): Sakura286 , wjh-la
, Rene Engelhard , Tor Lillqvist
There are currently 27 different, per-platform C++ UNO
C++ UNO bridge implementations
(bridges/source/cpp_uno/*)
Datum: Tue, 10 Jan 2023 17:31:12 +0100
Von:Stephan Bergmann
An: libreoff...@lists.freedesktop.org
Kopie (CC): Sakura286 , wjh-la
, Rene Engelhard , Tor Lillqvist
There are currently 27 different, per-platform C++ UNO
C++ UNO bridge implementations
(bridges/source/cpp_uno/*)
Datum: Tue, 10 Jan 2023 17:31:12 +0100
Von:Stephan Bergmann
An: libreoff...@lists.freedesktop.org
Kopie (CC): Sakura286 , wjh-la
, Rene Engelhard , Tor Lillqvist
There are currently 27 different, per-platform C++ UNO
C++ UNO bridge implementations
(bridges/source/cpp_uno/*)
Datum: Tue, 10 Jan 2023 17:31:12 +0100
Von:Stephan Bergmann
An: libreoff...@lists.freedesktop.org
Kopie (CC): Sakura286 , wjh-la
, Rene Engelhard , Tor Lillqvist
There are currently 27 different, per-platform C++ UNO
Ho,
Am 10. Januar 2023 09:27:16 MEZ schrieb Andreas Tille :
However, I get two failures
>> >when running its test suite:
>> >
>> >
>> >══ Failed tests
>> >
>> >── Failure ('test-encodings.R:16'): Dictionaries are found
>>
Hi,
Am 10. Januar 2023 08:01:31 MEZ schrieb Andreas Tille :
>> The problem per se is that you copy private stuff over.
>
>I'm aware that this is not a nice solution - I considered a bit better
>then keeping a full code copy of hunspell which is shipped by upstream.
Oh my... Yeah, it probably
Hi,
Am 09.01.23 um 21:40 schrieb Rene Engelhard:
The private headers now are for 1.7.2 - which as of now is in
experimental and thus you need to build against 1.7.2 (and probably have
a updated runtime dependency.)
Which is what my patch does in addition to the headers only.
https
Hi,
Am 09.01.23 um 21:18 schrieb Andreas Tille:
Control: tags -1 help
Erm, no? I think you mean #1028124, not this one (#1028130)?
I pushed some changes to git[1] that should fix this bug.
You only applied half of the patch in #1028124 so of course it breaks.
Unfortunately the package
Hi,
Am 9. Januar 2023 11:02:33 MEZ schrieb "Gábor Németh" :
>For a sanity check, I compiled the upstream from tag 7.4.4.2 with only
>the `--disable-gui` flag, and it worked.
Interesting. Also could be our way to populate -nogui which is a bit Jacky
> I suspected that maybe omitting
>one of
Hi,
Am 9. Januar 2023 11:02:33 MEZ schrieb "Gábor Németh" :
>For a sanity check, I compiled the upstream from tag 7.4.4.2 with only
>the `--disable-gui` flag, and it worked.
Interesting. Also could be our way to populate -nogui which is a bit Jacky
> I suspected that maybe omitting
>one of
[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
[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
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
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
Hi,
Am 08.01.23 um 05:40 schrieb - Etna:
3. Build error about implicit instantiation for
gtv-calc-header-bar.cxx and duplicate symbols for libetonyek occur.
Please see attachment.
https://cgit.freedesktop.org/libreoffice/core/log/?qt=grep=boost+1.81
libetonyek is
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.
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.
Package: r-cran-hunspell
Version: 3.0.2+dfsg-1
Severity: important
Tags: patch
Dear Maintainer,
I just noticed
/usr/lib/R/site-library/hunspell/dict/en_GB.aff
/usr/lib/R/site-library/hunspell/dict/en_GB.dic
/usr/lib/R/site-library/hunspell/dict/en_US.aff
to clean up generated files
+(closes: #1028123)
+
+ -- Rene Engelhard Sat, 07 Jan 2023 14:37:01 +
+
r-cran-hunspell (3.0.2+dfsg-1) unstable; urgency=medium
* New upstream version
diff -Nru r-cran-hunspell-3.0.2+dfsg/debian/control
r-cran-hunspell-3.0.2+dfsg/debian/control
--- r-cran
Package: lintian
Version: 2.115.3
Severity: important
Hi,
I get (well, got, it's overriden now)
libreoffice source: source-contains-prebuilt-windows-binary
on LibreOffices sw/qa/extras/txtimport/data/GB18030.txt
Looking at that file gives:
rene@frodo:~/LibreOffice/git/master$ cat
Package: lintian
Version: 2.115.3
Severity: important
Hi,
I get (well, got, it's overriden now)
libreoffice source: source-contains-prebuilt-windows-binary
on LibreOffices sw/qa/extras/txtimport/data/GB18030.txt
Looking at that file gives:
rene@frodo:~/LibreOffice/git/master$ cat
private) htypes.hxx and csutil.hxx to fix build
+with hunspell 1.7.2. Bump build-dependency
+ * add override_dh_auto_clean to clean up generated files
+
+ -- Rene Engelhard Sat, 07 Jan 2023 14:35:07 +0100
+
r-cran-hunspell (3.0.2+dfsg-1) unstable; urgency=medium
* New upstream vers
-S -i
dpkg-buildpackage: info: source package r-cran-hunspell
dpkg-buildpackage: info: source version 3.0.2+dfsg-1.1
dpkg-buildpackage: info: source distribution unstable
dpkg-buildpackage: info: source changed by Rene Engelhard
dpkg-source -i --before-build .
debian/rules clean
dh clean
Hi,
Am 04.01.23 um 10:18 schrieb Thomas Goirand:
The latest update of boost was in late 2020. Why are we waiting so
late in the release cycle to do such a transition? The month of the
freeze is *NOT* a good moment to do it.
Indeed.
Regards,
Rene
Hi,
Am 04.01.23 um 10:37 schrieb Thomas Goirand:
On 1/4/23 06:24, Anton Gladky wrote:
apt install libboost-dev -t experimental
FYI, Ceph FTBFS with it... :/
As did LibreOffice - already fixed by
$ cat debian/patches/boost-1.81.diff
From 7e61545966c61102aad56bbf10bae2edfbfa9226 Mon Sep 17
Hi,
Am 02.01.23 um 05:05 schrieb Changwoo Ryu:
It's correct that the minimal system installed by autopkgtest has
always python3. Isn't the test supposed to be run by autopkgtest?
You can also just run it manually if it was a script (by running
./tests/foo), also you can just copy the command
Hi,
Am 02.01.23 um 05:05 schrieb Changwoo Ryu:
It's correct that the minimal system installed by autopkgtest has
always python3. Isn't the test supposed to be run by autopkgtest?
You can also just run it manually if it was a script (by running
./tests/foo), also you can just copy the command
Hi,
Am 01.01.23 um 21:25 schrieb Changwoo Ryu:
I can't reproduce it myself.
I am not sure either what happens...
In your test, every word failed to be checked with the same error and
the error message came from hunspell, when iconv() conversion on text
fails. Probably your chroot environment
Hi,
Am 01.01.23 um 21:25 schrieb Changwoo Ryu:
I can't reproduce it myself.
I am not sure either what happens...
In your test, every word failed to be checked with the same error and
the error message came from hunspell, when iconv() conversion on text
fails. Probably your chroot environment
Hi,
Am 01.01.23 um 21:25 schrieb Changwoo Ryu:
I can't reproduce it myself.
I am not sure either what happens...
In your test, every word failed to be checked with the same error and
the error message came from hunspell, when iconv() conversion on text
fails. Probably your chroot environment
Source: hunspell
Version: 1.7.2+really1.7.1-2
Severity: serious
1.7.2+really1.7.1-2 is - as the name says - a reupload of 1.7.1 because
1.7.2 broke autopkgtests and this needs to be investigated.
Since there is no change here and there probably (in case it happened we
can lift the block) is no
Source: hunspell
Version: 1.7.2+really1.7.1-2
Severity: serious
1.7.2+really1.7.1-2 is - as the name says - a reupload of 1.7.1 because
1.7.2 broke autopkgtests and this needs to be investigated.
Since there is no change here and there probably (in case it happened we
can lift the block) is no
Source: hunspell
Version: 1.7.2+really1.7.1-2
Severity: serious
1.7.2+really1.7.1-2 is - as the name says - a reupload of 1.7.1 because
1.7.2 broke autopkgtests and this needs to be investigated.
Since there is no change here and there probably (in case it happened we
can lift the block) is no
Source: hunspell-dict-ko
Version: 0.7.92-1
Severity: serious
Hi,
while looking at the autopkgtest failure in
https://ci.debian.net/data/autopkgtest/testing/amd64/h/hunspell-dict-ko/29793472/log.gz
I tried it here myself.
It even fails here locally with 1.7.2+really1.7.1-2 which I needed to
Source: hunspell-dict-ko
Version: 0.7.92-1
Severity: serious
Hi,
while looking at the autopkgtest failure in
https://ci.debian.net/data/autopkgtest/testing/amd64/h/hunspell-dict-ko/29793472/log.gz
I tried it here myself.
It even fails here locally with 1.7.2+really1.7.1-2 which I needed to
Source: hunspell-dict-ko
Version: 0.7.92-1
Severity: serious
Hi,
while looking at the autopkgtest failure in
https://ci.debian.net/data/autopkgtest/testing/amd64/h/hunspell-dict-ko/29793472/log.gz
I tried it here myself.
It even fails here locally with 1.7.2+really1.7.1-2 which I needed to
Source: hunspell-dict-ko
Version: 0.7.92-1
Severity: important
Dear Maintainer,
I tried to look after the hunspell-dict-ko failure and created a minimal
chroot + installing the test
dependencies for that.
I got:
rene@frodo:~/hunspell-dict-ko-0.7.92$ make hosttest
Source: hunspell-dict-ko
Version: 0.7.92-1
Severity: important
Dear Maintainer,
I tried to look after the hunspell-dict-ko failure and created a minimal
chroot + installing the test
dependencies for that.
I got:
rene@frodo:~/hunspell-dict-ko-0.7.92$ make hosttest
+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
+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
Hallo,
Am 27.12.22 um 07:46 schrieb Johannes Schauer Marin Rodrigues:
[build CXX] cui/source/dialogs/QrCodeGenDialog.cxx
S=/<> && I=$S/instdir && W=$S/workdir && mkdir -p $W/CxxObject/cui/source/dialogs/
$W/Dep/CxxObject/cui/source/dialogs/ && cd /<> && aarch64-linux-gnu-g++
Hallo,
Am 27.12.22 um 07:46 schrieb Johannes Schauer Marin Rodrigues:
[build CXX] cui/source/dialogs/QrCodeGenDialog.cxx
S=/<> && I=$S/instdir && W=$S/workdir && mkdir -p $W/CxxObject/cui/source/dialogs/
$W/Dep/CxxObject/cui/source/dialogs/ && cd /<> && aarch64-linux-gnu-g++
reassign 962582 libreoffice-common
forcemerge 962582 955271
thanks
Hi,
Am 23.12.22 um 15:17 schrieb Teemu Likonen:
This bug was closed, possibly because of you not getting answer from me.
Sorry, I missed your post in 2022-10-09. A bit more information is
below, and it's good news.
[...]
reassign 962582 libreoffice-common
forcemerge 962582 955271
thanks
Hi,
Am 23.12.22 um 15:17 schrieb Teemu Likonen:
This bug was closed, possibly because of you not getting answer from me.
Sorry, I missed your post in 2022-10-09. A bit more information is
below, and it's good news.
[...]
Package: dpkg
Version: 1.21.12
Severity: important
Hi,
libuno-cppuhelpergcc3-3 has
Depends: ${misc:Depends}, ${shlibs:Depends}, uno-libs-private (=
${binary:Version})
which then boils down to (uninteresting stuff stripped):
# apt-cache show libuno-cppuhelpergcc3-3
Package:
Package: dpkg
Version: 1.21.12
Severity: important
Hi,
libuno-cppuhelpergcc3-3 has
Depends: ${misc:Depends}, ${shlibs:Depends}, uno-libs-private (=
${binary:Version})
which then boils down to (uninteresting stuff stripped):
# apt-cache show libuno-cppuhelpergcc3-3
Package:
Hi,
Am 08.12.22 um 19:59 schrieb Jon Daley:
Right - so I would think any default browser would work in actual use
(if someone is using elinks as their default browser, they know what
they are getting into).
Or just didn't know that LibreOffice helps needs JS and thus it does't
work (see my
Hi,
Am 08.12.22 um 19:59 schrieb Jon Daley:
Right - so I would think any default browser would work in actual use
(if someone is using elinks as their default browser, they know what
they are getting into).
Or just didn't know that LibreOffice helps needs JS and thus it does't
work (see my
701 - 800 of 26080 matches
Mail list logo
