On 12/8/23 11:30, Michael Stahl wrote:
... considering that LO uses UTF-16 strings for everything including
file paths, perhaps the best thing would be to add a check for the "C"
locale on startup, print an error and abort.
The situation for the ASCII "C" locale is not much different here from
On 08.12.2023 13:30, Michael Stahl wrote:
On 04/12/2023 13:05, Stephan Bergmann wrote:
On 12/4/23 12:10, Michael Stahl wrote:
On 03/12/2023 12:59, Stephan Bergmann wrote:
For better or worse, the payload of LO "internal" file URLs is
always considered to be a UTF-8 encoding of the actual syste
On 04/12/2023 13:05, Stephan Bergmann wrote:
On 12/4/23 12:10, Michael Stahl wrote:
On 03/12/2023 12:59, Stephan Bergmann wrote:
For better or worse, the payload of LO "internal" file URLs is always
considered to be a UTF-8 encoding of the actual system pathname. It
is *not* a byte-for-byte r
On 12/4/23 12:10, Michael Stahl wrote:
On 03/12/2023 12:59, Stephan Bergmann wrote:
For better or worse, the payload of LO "internal" file URLs is always
considered to be a UTF-8 encoding of the actual system pathname. It
is *not* a byte-for-byte representation of the bytes that make up the
U
On 03/12/2023 12:59, Stephan Bergmann wrote:
On 12/2/23 16:38, Mike Kaganski wrote:
On 02.12.2023 17:46, Rene Engelhard wrote:
In any case this is bad. My filesystem (I think from 2020 or so)
apparently shows it (ls -l does) but I wouldn't be sure for other,
old ones (like Debians build machin
On 12/3/23 14:13, Rene Engelhard wrote:
But in my case this fails with
cd $(SOURCE_TREE) && \
export PATH=$(BUILD_PATH); \
export TMPDIR=$$t; \
export HOME=$$t; \
export LOCPATH=$(CURDIR)/debian/locales; \
Hi,
Am 03.12.23 um 14:13 schrieb Rene Engelhard:
I did some more tests.
In my standard local build environment (cowbuilder[1] --login chroot)
it fails.
if I chroot() into exactly that same chroot (as it is on disk), it works.
If I use a pbuilder --login chroot it succeeds.
Sorry, apparent
Hi,
Am 03.12.23 um 12:59 schrieb Stephan Bergmann:
On 12/2/23 16:38, Mike Kaganski wrote:
On 02.12.2023 17:46, Rene Engelhard wrote:
In any case this is bad. My filesystem (I think from 2020 or so)
apparently shows it (ls -l does) but I wouldn't be sure for other,
old ones (like Debians build
On 12/2/23 16:38, Mike Kaganski wrote:
On 02.12.2023 17:46, Rene Engelhard wrote:
In any case this is bad. My filesystem (I think from 2020 or so)
apparently shows it (ls -l does) but I wouldn't be sure for other, old
ones (like Debians build machines). The locale this fails under
definitely i
Hi!
On 02.12.2023 17:46, Rene Engelhard wrote:
In any case this is bad. My filesystem (I think from 2020 or so)
apparently shows it (ls -l does) but I wouldn't be sure for other, old
ones (like Debians build machines). The locale this fails under
definitely is UTF-8 though.
This tells that t
Hi again,
for advoidance of doubt:
I said:
> I think this change should be reverted.
I mean:
From 8a0015c35f3f137e4f3a80e40616bc078e265a1c Mon Sep 17 00:00:00 2001
From: Mike Kaganski
Date: Fri, 1 Dec 2023 16:43:49 +0300
Subject: Drop allownonascii check from pre-commit checks
That one s
Hi,
After a recent pull of master I get
[build CUT] filter_textfilterdetect
S=/home/rene/LibreOffice/git/master && I=$S/instdir && W=$S/workdir &&
mkdir -p $W/CppunitTest/ && rm -fr
$W/CppunitTest/filter_textfilterdetect.test.user && cp -r $W/unittest
$W/CppunitTest/filter_textfilterdetect.te
12 matches
Mail list logo
