Bug#999262: mythes: missing required debian/rules targets build-arch and/or build-indep

[Rene Engelhard]

Hi,

Am 9. November 2021 22:28:18 MEZ schrieb Lucas Nussbaum :
>Your package does not include build-arch and/or build-indep targets in
>debian/rules. This is required by Debian Policy section 4.9, since 2012.
>https://www.debian.org/doc/debian-policy/ch-source.html#main-building-script-debian-rules

In 3.9.4.

Standards-Version: of this package is 3.6.1.

And this does not even build indep packages...

Waste of time for adding a no-oop...

>Please note that this is also a sign that the packaging of this software
>could benefit from a refresh. For example, packages using 'dh' cannot be
>affected by this issue.
>

And would not bring any gain.

>This mass bug filing was discussed on debian-devel@ in
>https://lists.debian.org/debian-devel/2021/11/msg00052.html .

Wow, 5 days.

>The severity of this bug will be changed to 'serious' after a month.

You are kidding? The package follows police as specified. You have a good 
talent of wasting people's time (there's other stuff than Debian) für no gain.

Regards,

Rene
-- 
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.

Bug#998753: libreoffice: Please add support for webp image format

[Rene Engelhard]

forwarded 998753 https://bugs.documentfoundation.org/show_bug.cgi?id=114532

tag 998753 + upstream

thanks


Hi,


Am 07.11.21 um 17:29 schrieb Diederik de Haas:

[...]

> I was/am creating a document and I wanted to add an image I saved from a
> webpage (from 2017( which had the file extension .png.
> But that failed with the message: "Unknown image format"
>
> IIRC with 7.2.2 the msg was ~ "Unknown image filter", so that has
> improved as the file selection dialog has a "Filter" field and I didn't
> understand what I did wrong because of that.
> Until I ran the 'file' command on that image file and saw it actually
> was a webp image and not a png as the file extension indicated.
>
> I can/will work around it by converting it to (actual) png or jpg, but I
> didn't expect that webp image format would not be supported by LO and
> thereby didn't allow me to insert the image.
> So hereby the request to add support for webp to LO.
>
Pretty a job for upstream, eh?

(See https://bugs.documentfoundation.org/show_bug.cgi?id=114532)


Regards,


Rene

Bug#998746: marked as done (/usr/lib/libreoffice/program/libmergedlo.so: undefined symbol: _ZN8MsLangId17getSystemLanguageEv)

[Rene Engelhard]

reopen 998746

found 998746 1:7.3.0~alpha1-1

thanks


Hi,


> When you mix (and not match) different versions, problems can easily
occur.
> After doing "aptitude safe-upgrade ~i~V1:7.2.2-1 -t experimental", I
could
> successfully launch LO Writer, so closing the bug again.

Especially in experimental... Where this upload was just for build and
autopkgtest testing mainly (which don't test partial upgrades, though -
and are broken right now anyways - to be fixed when I get all the
test-autopkgtest runs working) :)


But:


$ libreoffice
Warning: failed to launch javaldx - java may not function correctly
/usr/lib/libreoffice/program/soffice.bin: symbol lookup error:
/usr/lib/libreoffice/program/libmergedlo.so: undefined symbol:
_ZN8MsLangId17getSystemLanguageEv


Ah, that again, seems again a case similar as of
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=994624 ...

Just that in this case it simply seems to be a new function, thus no
Breaks: needed..


Regards,


Rene

Bug#998733: libnss3-dev: please add Breaks: libxmlsec1-dev (<< 1.2.33-1)

[Rene Engelhard]

Package: libnss3-dev
Version: 2:3.72-1
Severity: wishlist

Hi,

as said in https://lists.debian.org/debian-release/2021/11/msg00018.html
(#998339) nss 2:3.72-1 removes xulrunner-nss.pc which xmlsec1-nss.pc
relied on.

This has now been fixed in xmlsec1 1.2.33-1.
(Which at the time of this writing is 3/5 days old and if this migrated
in 2 days the "libreoffice regression" caused by this should sort itself
out itself and nss migrate then some time after(

But I think libnss3-dev should add appropriate Breaks: for eventual
partial upgrades.

Regards,

Rene

Bug#997089: libreoffice: FTBFS: segfault in '/<>/instdir/sdk/examples/java/Inspector'

[Rene Engelhard]

severity 997089 minor

thanks


Am 03.11.21 um 17:27 schrieb Lucas Nussbaum:
> On 03/11/21 at 17:13 +0100, Rene Engelhard wrote:
>> Hi,
>>
>> Am 03.11.21 um 08:05 schrieb Lucas Nussbaum:
>>> If it's truly a random failure, it might be better to downgrade it but
>>> keep it open,
>> I don't really like this. I don't like open bugs which definitely will
>> never get attention.
>>>  so that another bug does not get opened in future
>>> rebuilds.
>> Sure? A minor bug will be looked at when looking at rebuilds? Important
>> and even normal is too much here even.
> At least by me, yes, since I look at bugs based on string matches in the
> bug titles (ftbfs, build, etc.)

Let's do that then.


Regards,


Rene

Bug#997089: libreoffice: FTBFS: segfault in '/<>/instdir/sdk/examples/java/Inspector'

[Rene Engelhard]

Hi,

Am 03.11.21 um 08:05 schrieb Lucas Nussbaum:
> If it's truly a random failure, it might be better to downgrade it but
> keep it open,
I don't really like this. I don't like open bugs which definitely will
never get attention.
>  so that another bug does not get opened in future
> rebuilds.

Sure? A minor bug will be looked at when looking at rebuilds? Important
and even normal is too much here even.


Regards,


Rene

Bug#997089: libreoffice: FTBFS: segfault in '/<>/instdir/sdk/examples/java/Inspector'

[Rene Engelhard]

Hi,

Am Thu, Oct 28, 2021 at 07:18:19PM +0200 schrieb Rene Engelhard:
> And interestingly, (after rm'ing the stale unopkg lockfile..) it passed.
> 
> Also after a new attempt with manual
> 
> $ make clean && make subsequencheck
> 
> in odk worked, too.
> 
> 
> Just looks like a flaky test... (Even though I saw it the first time
> here with this report..)

And since then various test build on my laptop, both 7.3 and 7.2 worked,
as did it on the buildd:

https://buildd.debian.org/status/logs.php?pkg=libreoffice=all
(alpha1-1 was a other breakage fixed in -2, -2 failed for an other
reason)
https://buildd.debian.org/status/logs.php?pkg=libreoffice=amd64
https://buildd.debian.org/status/logs.php?pkg=libreoffice=arm64

Can we close this?

Regards,
 
Rene

Bug#998339: nmu: xmlsec1_1.2.32-2

[Rene Engelhard]

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

Bug#997089: libreoffice: FTBFS: segfault in '/<>/instdir/sdk/examples/java/Inspector'

[Rene Engelhard]

Hi again,

Am 28.10.21 um 18:11 schrieb Rene Engelhard:
> Am 23.10.21 um 18:41 schrieb Lucas Nussbaum:
>> [...]

>> "/<>/instdir/program/unopkg" add -f
>> "/<>/workdir/CustomTarget/odk/build-examples_java/out/sdk/LINUXexample.out/bin/Inspector.oxt"
>>
>>> Segmentation fault (core dumped)
>>> make[5]: *** [Makefile:168: 
>>> /<>/workdir/CustomTarget/odk/build-examples_java/out/sdk/LINUXexample.out/misc/InstanceInspector/Inspector/java_Inspector_register_component.flag]
>>>  Error 139
> Jup. Seeing this in a master build, too :(
>
>
> Incidentially this worked fine until the day before you filed the 
> bugreport. Also interestingly, in a clean chroot the
> odk-build-examples-java test (which does the exact thing as above)
> _does_ pass..

And interestingly, (after rm'ing the stale unopkg lockfile..) it passed.

Also after a new attempt with manual

$ make clean && make subsequencheck

in odk worked, too.


Just looks like a flaky test... (Even though I saw it the first time
here with this report..)


Regards,


Rene

Bug#997089: libreoffice: FTBFS: segfault in '/<>/instdir/sdk/examples/java/Inspector'

[Rene Engelhard]

[ sorry for the late answer, needed to get a new laptop as the battery
broke badly.. ]

Hi,

Am 23.10.21 um 18:41 schrieb Lucas Nussbaum:
> make[5]: Entering directory
> '/<>/instdir/sdk/examples/java/Inspector'
>> mkdir -p 
>> /<>/workdir/CustomTarget/odk/build-examples_java/out/sdk/LINUXexample.out/misc/InstanceInspector
>> "/<>/instdir/sdk/bin/idlc" -C -I. -I../../../idl 
>> -O/<>/workdir/CustomTarget/odk/build-examples_java/out/sdk/LINUXexample.out/misc/InstanceInspector
>>  InstanceInspector.idl
>> Compiling: InstanceInspector.idl
>> mkdir -p 
>> /<>/workdir/CustomTarget/odk/build-examples_java/out/sdk/LINUXexample.out/misc/InstanceInspector
>> "/<>/instdir/sdk/bin/idlc" -C -I. -I../../../idl 
>> -O/<>/workdir/CustomTarget/odk/build-examples_java/out/sdk/LINUXexample.out/misc/InstanceInspector
>>  XInstanceInspector.idl
>> Compiling: XInstanceInspector.idl
>> rm -f 
>> /<>/workdir/CustomTarget/odk/build-examples_java/out/sdk/LINUXexample.out/misc/InstanceInspector/Inspector/Inspector.uno.rdb
>> mkdir -p 
>> /<>/workdir/CustomTarget/odk/build-examples_java/out/sdk/LINUXexample.out/misc/InstanceInspector/Inspector
>> "/<>/instdir/program/regmerge" 
>> /<>/workdir/CustomTarget/odk/build-examples_java/out/sdk/LINUXexample.out/misc/InstanceInspector/Inspector/Inspector.uno.rdb
>>  /UCR 
>> /<>/workdir/CustomTarget/odk/build-examples_java/out/sdk/LINUXexample.out/misc/InstanceInspector/InstanceInspector.urd
>>  
>> /<>/workdir/CustomTarget/odk/build-examples_java/out/sdk/LINUXexample.out/misc/InstanceInspector/XInstanceInspector.urd
>> mkdir -p 
>> /<>/workdir/CustomTarget/odk/build-examples_java/out/sdk/LINUXexample.out/misc/InstanceInspector/Inspector
>> mkdir -p 
>> /<>/workdir/CustomTarget/odk/build-examples_java/out/sdk/LINUXexample.out/class/InstanceInspector/org/openoffice
>> "/<>/instdir/sdk/bin/javamaker" -nD 
>> -Torg.openoffice.InstanceInspector  -Torg.openoffice.XInstanceInspector  
>> -O/<>/workdir/CustomTarget/odk/build-examples_java/out/sdk/LINUXexample.out/class/InstanceInspector
>>  
>> /<>/workdir/CustomTarget/odk/build-examples_java/out/sdk/LINUXexample.out/misc/InstanceInspector/Inspector/Inspector.uno.rdb
>>  -X"/<>/instdir/program/types.rdb" 
>> -X"/<>/instdir/program/types/offapi.rdb"
>> mkdir -p 
>> /<>/workdir/CustomTarget/odk/build-examples_java/out/sdk/LINUXexample.out/class/InstanceInspector/org/openoffice
>> "/<>/instdir/sdk/bin/javamaker" -nD 
>> -Torg.openoffice.InstanceInspector  -Torg.openoffice.XInstanceInspector  
>> -O/<>/workdir/CustomTarget/odk/build-examples_java/out/sdk/LINUXexample.out/class/InstanceInspector
>>  
>> /<>/workdir/CustomTarget/odk/build-examples_java/out/sdk/LINUXexample.out/misc/InstanceInspector/Inspector/Inspector.uno.rdb
>>  -X"/<>/instdir/program/types.rdb" 
>> -X"/<>/instdir/program/types/offapi.rdb"
>> mkdir -p 
>> /<>/workdir/CustomTarget/odk/build-examples_java/out/sdk/LINUXexample.out/class/InstanceInspector/Inspector
>> "/usr/lib/jvm/default-java/bin/javac"  -classpath 
>> "/<>/instdir/program/classes/libreoffice.jar:/<>/instdir/program/classes/unoloader.jar::/<>/workdir/CustomTarget/odk/build-examples_java/out/sdk/LINUXexample.out/class/InstanceInspector:/<>/workdir/CustomTarget/odk/build-examples_java/out/sdk/LINUXexample.out/class/InstanceInspector/Inspector"
>>  -sourcepath . -d 
>> /<>/workdir/CustomTarget/odk/build-examples_java/out/sdk/LINUXexample.out/class/InstanceInspector/Inspector
>>  XDialogProvider.java
>> Note: ./MethodParametersDialog.java uses unchecked or unsafe operations.
>> Note: Recompile with -Xlint:unchecked for details.
>> mkdir -p 
>> /<>/workdir/CustomTarget/odk/build-examples_java/out/sdk/LINUXexample.out/class/InstanceInspector/Inspector
>> "/usr/lib/jvm/default-java/bin/javac"  -classpath 
>> "/<>/instdir/program/classes/libreoffice.jar:/<>/instdir/program/classes/unoloader.jar::/<>/workdir/CustomTarget/odk/build-examples_java/out/sdk/LINUXexample.out/class/InstanceInspector:/<>/workdir/CustomTarget/odk/build-examples_java/out/sdk/LINUXexample.out/class/InstanceInspector/Inspector"
>>  -sourcepath . -d 
>> /<>/workdir/CustomTarget/odk/build-examples_java/out/sdk/LINUXexample.out/class/InstanceInspector/Inspector
>>  XTreeControlProvider.java
>> mkdir -p 
>> /<>/workdir/CustomTarget/odk/build-examples_java/out/sdk/LINUXexample.out/class/InstanceInspector/Inspector
>> "/usr/lib/jvm/default-java/bin/javac"  -classpath 
>> "/<>/instdir/program/classes/libreoffice.jar:/<>/instdir/program/classes/unoloader.jar::/<>/workdir/CustomTarget/odk/build-examples_java/out/sdk/LINUXexample.out/class/InstanceInspector:/<>/workdir/CustomTarget/odk/build-examples_java/out/sdk/LINUXexample.out/class/InstanceInspector/Inspector"
>>  -sourcepath . -d 
>> /<>/workdir/CustomTarget/odk/build-examples_java/out/sdk/LINUXexample.out/class/InstanceInspector/Inspector
>>  XTreePathProvider.java
>> mkdir -p 
>> /<>/workdir/CustomTarget/odk/build-examples_java/out/sdk/LINUXexample.out/class/InstanceInspector/Inspector
>> 

Bug#996912: RM: libjuh-java,libjurt-java,libridl-java,libunoil-java -- ROM; NBS

[Rene Engelhard]

Package: ftp.debian.org
Severity: normal

Hi,

please remove

$ rmadison -s unstable libjuh-java libridl-java libunoil-java libjurt-java
libjuh-java   | 1:7.0.4-4 | unstable   | all
libjurt-java  | 1:7.0.4-4 | unstable   | all
libridl-java  | 1:7.0.4-4 | unstable   | all
libunoil-java | 1:7.0.4-4 | unstable   | all

They are obsolete long ago:

libreoffice (1:7.1.0~alpha1-1) experimental; urgency=medium

  * New upstream alpha release

  * debian/rules:
- add conditional and build-dep for new box2d (again)
- don't parse parallel=X manually but use dpkg-devs buildopts.mk
- build only en-US for now
- try to enable pdfium anywhere since configure says
  "Disable building PDFium. Results in unsecure PDF signature
  verification."
  * debian/control*in, debian/rules:
- split Java parts of the URE to ure-java so that libreoffice-java-common
  can depend on that. (For possible future archs starting with
  no-java where this then isn't fullfillable instead of silently "working"
  without actual Java stuff in "ure")
- stop building libjuh-java, libridl-java, libjurt-java and libunoil-java.
  Merge them (and provide them) in(to) liblibreoffice-java.

 -- Rene Engelhard   Tue, 27 Oct 2020 18:04:25 +0100

but not removed by auto-cruft when this was uploaded to sid after the
buster release.

Note that dak rm might complain about r-deps, but those all are having
unversioned dependencies and:

Provides: libjuh-java, libjurt-java, libridl-java, libunoil-java
Depends: libunoloader-java, ure-java
Breaks: libjuh-java (<< 1:7.1.0~), libjurt-java (<< 1:7.1.0~), libridl-java (<< 
1:7.1.0~), libunoil-java (<< 1:7.1.0~)
Replaces: libjuh-java (<< 1:7.1.0~), libjurt-java (<< 1:7.1.0~), libridl-java 
(<< 1:7.1.0~), libunoil-java (<< 1:7.1.0~)

in liblibreoffice-java.

Regards,

Rene

Bug#912178: muttprint: Please add homepage link to d/control

[Rene Engelhard]

Hi,

Am 14.10.21 um 10:38 schrieb Petter Reinholdtsen:
> [Rene Engelhard]
>> There is https://salsa.debian.org/rene/muttprint/-/tree/master
> Right.  Very good.  I notice it is lacking a few of the latest uploads.

For some value of "recent" :)

Since oldoldstable ;-)


> I tried to transfer it to the Debian group, but lack the necessecary
> privileges.  I suspect you will have to visit
> https://salsa.debian.org/rene/muttprint/edit >, select advanced
> options, move to the transfer section and move it to the Debian
> namespace.

done

> Btw, did you update some files to register my co-maintenance of
> muttprint?  If so, where?

No, feel free to add it to the new debian repos.


Regards,


Rene

Bug#912178: muttprint: Please add homepage link to d/control

[Rene Engelhard]

Hi,

Am 14.10.21 um 09:30 schrieb Petter Reinholdtsen:
> I still remember how, and can do it in the next few days. One key
> question is if you already have a git repository (or some other VCS) for
> the package we should migrate, or if I should rebuild one from scratch
> using git-buildpackage? 

There is https://salsa.debian.org/rene/muttprint/-/tree/master

> The latter option include importing the history as uploaded to unstable.

which also needs gbp import --debsnap to update to reality...


Regards,


Rene

Bug#912178: muttprint: Please add homepage link to d/control

[Rene Engelhard]

Hi,

Am 14.10.21 um 08:22 schrieb Petter Reinholdtsen:
> Control: tags -1 +patch
>
> As the homepage link is still missing, perhaps a patch is needed to
> solve this issue?  Also include a d/upstream/metadata file with some key
> values.
>
> diff --git a/debian/control b/debian/control
> index 0806f4d..81c84d3 100644
> --- a/debian/control
> +++ b/debian/control
> @@ -4,6 +4,7 @@ Priority: optional
>  Maintainer: Rene Engelhard 
>  Build-Depends: debhelper (>= 9), imagemagick, ghostscript, docbook-utils, 
> sharutils, dh-autoreconf, automake, autoconf, docbook
>  Standards-Version: 3.6.2
> +Homepage: http://muttprint.sourceforge.net/
Well, given muttprint seems pretty dead upstream...
>  
>  Package: muttprint
>  Architecture: all
> diff --git a/debian/upstream/metadata b/debian/upstream/metadata
> new file mode 100644
> index 000..f05c737
> --- /dev/null
> +++ b/debian/upstream/metadata
> @@ -0,0 +1,6 @@
> +Archive: SourceForge
> +Contact: Lukas Ruf 
> +CPE: cpe:/a:lukas_ruf:muttprint
> +Bug-Database: https://sourceforge.net/p/muttprint/bugs/
> +Repository: https://sourceforge.net/projects/muttprint/
> +Repository-Browse: https://sourceforge.net/p/muttprint/code/HEAD/tree/
>
> Rene, do you need a co-maintainer for this package?  I might be able to
> help out a bit.
Sure, could do. Busy with other packages (and using muttprint only
seldomly by now.)
>   If so, what about maintaining it using gbp-buildpackage
> under https://salsa.debian.org/debian >?

Could do.

(Actually I forgot how to properly move stuff in salsa, though; added
you as maintainer now).


You can also take it over completely if you wish :-)


Regards,


Rene

Bug#996016: libreoffice: fails to send email

[Rene Engelhard]

[ please always keep the Bug in CC so that discussions about it get
recorded.

Readding. ]


Hi.

Am 10.10.21 um 20:44 schrieb Alex:
> And what is in LO settings?
> LO Settings point to /usr/lib/thunderbird

OK, as I guessed. Then anything can be in KDEs session doesn't matter.

> What if you set your mailer as xdg-email?
>
>
> That works as expected. Thanks.
>
As expected. And xdg-email knows what you want thunderbird :-)

> I just tried it: LOs default has sensible-lomua set. That one opened
>> Thunderbird in my  GNOME and happily set mail.
>>
Although best is to keep it as sensible-lomua which then runs xdg-open
>> case `basename "$MAILER"` in
>>  sensible-lomua)
>>  if [ -x /usr/bin/xdg-email ] ; then
>>  MAILER=/usr/bin/xdg-email

[...]


And as said sensible-lomua (which is the default setting in LO) is more
or less a redirection also defaulting to actually calling xdg-email anyway.


Can we close this as "user configuration error"? :)


Regards,


Rene

Bug#996016: libreoffice: fails to send email

[Rene Engelhard]

found 996016 1:7.0.4-4

retitlle 996016 ibreoffice: fails to send email with Thunderbird set as
mailer in KDE

tag 996016 + moreinfo

tag 996016 + unreproducible

thanks


Hi,


Am 10.10.21 um 11:30 schrieb Alex:
> Package: libreoffice
> Severity: normal
>
> Dear Maintainer,
>
> When I created a document in libreoffice and when I would send it as
> mail attachment, Libreoffice simply doesn't open my mailprogram
> defined in KDE.
> When I start libreoffice in a shell, I got error messages when sending
> the document as mail. In fact, I defined Thunderbird as my mail
> program in KDE->Settings.
And what is in LO settings?

> As you can see, I got a permission denied on /usr/bin/thunderbird. I
checked the permissions and those seemed to be ok, and when I start
thunderbird directly in the shell, it will start.

> So I disabled apparmor. I completely uninstalled it and after a
> reboot, the sending by mail attachment works as expected.
>
> This is only an ugly workaround to get it work again, so help please.
>
What if you set your mailer as xdg-email? That one is explicitely allowed:


profile libreoffice-senddoc /usr/lib/libreoffice/program/senddoc {
  #include 

  #include 

  /{usr/,}bin/sh    rmix,
  /{usr/,}bin/bash  rmix,
  /{usr/,}bin/dash  rmix,
  /{usr/,}bin/sed   rmix,
  /usr/bin/dirname  rmix,
  /usr/bin/basename rmix,
  /{usr/,}bin/grep  rmix,
  /{usr/,}bin/uname rmix,
  /usr/bin/xdg-open rPUx,
  /usr/bin/xdg-email    rPUx,
  /dev/null rw,
  /usr/lib/libreoffice/program/uri-encode rmpux,
  /usr/share/libreoffice/share/config/* r,
  owner
@{HOME}/.config/libreoffice{,dev}/?/user/uno_packages/cache/log.txt rw,
}


xdg-email will send with your preferred e-mail programm (see man xdg-email).


I just tried it: LOs default has sensible-lomua set. That one opened
Thunderbird in my  GNOME and happily set mail.

case `basename "$MAILER"` in
    sensible-lomua)
    if [ -x /usr/bin/xdg-email ] ; then
    MAILER=/usr/bin/xdg-email
    elif [ -n "$KDE_FULL_SESSION" -a -x /usr/bin/kde-open ] \
   || [ -x /usr/bin/gnome-open ] \
   || [ -x /usr/bin/xdg-open ]; then
    # use an undefined mailer, to trigger the default handling
    MAILER=undefined
    elif [ -n "$GNOME_DESKTOP_SESSION_ID" -a -x /usr/bin/evolution
]; then
    MAILER=/usr/bin/evolution
    elif [ -n "$KDE_FULL_SESSION" -a -x /usr/bin/kmail ]; then
    MAILER=/usr/bin/kmail
    elif [ -x /usr/bin/evolution ]; then
    # default
    MAILER=/usr/bin/evolution
    elif [ -x /usr/bin/icedove ]; then
    # fallback
    MAILER=/usr/bin/icedove
    elif [ -x /usr/bin/thunderbird ]; then
    # fallback
    MAILER=/usr/bin/thunderbird
    fi
    ;;
esac


... using xdg-email.

Regards,


Rene

Bug#994757: libgraphite2-dev: no archive files for static compilation are included in the -dev package

[Rene Engelhard]

tag 994757 + wontfix

thanks

Hi,

Am 22.09.21 um 17:56 schrieb Alfonso Sanchez-Beato:

> and that in general having the option to compile statically cannot be
harmful.

I disagree. It's probably usedul for essential stuff but not for GUI
stuff. (and graphite is about fonts, so GUI).


There actually is effort in Debian to get rid of .as and MANY packages
don't ship .as anymore. I am not convinced adding a new .a now is a way
forward.


Regards,


Rene

Bug#994757: libgraphite2-dev: no archive files for static compilation are included in the -dev package

[Rene Engelhard]

Hi again,

Am 22.09.21 um 18:08 schrieb Rene Engelhard:
> Hi,
>> Do you want me to create a new bug? I was about to do it, but thought
>> that would create more noise by now.
> 
> obviously not. if you read the bug you'd have seen that I fixed the
> metadata. 

I am sorry, actually I didn't remove the wrong found (cut'n'paste error
in the command), nevermind..

Regards,

Rene

Bug#994757: libgraphite2-dev: no archive files for static compilation are included in the -dev package

[Rene Engelhard]

Hi,
> Do you want me to create a new bug? I was about to do it, but thought
> that would create more noise by now.

obviously not. if you read the bug you'd have seen that I fixed the
metadata. Yes,a new bug would be  useless noise.


Regards,


Rene

Bug#994757: libgraphite2-dev: no archive files for static compilation are included in the -dev package

[Rene Engelhard]

notfound 994757 1.3.13-11

severity 994757 wishlist

thanks

Hi,

Am 20.09.21 um 16:43 schrieb Alfonso Sanchez-Beato:
> Package: libgraphite2-dev
> Version: 1.3.13-11build1

There is no such version. You are reporting against Debian, please use
proper versions existing there.


Also you are reporting against a obsolete version which doesn't exist
anymore (and in stable stuff like this won't be changed):

$ rmadison libgraphite2-dev

libgraphite2-dev | 1.3.13-7    | oldstable   | amd64, arm64,
armel, armhf, i386, mips, mips64el, mipsel, ppc64el, s390x
libgraphite2-dev | 1.3.14-1    | stable  | amd64, arm64,
armel, armhf, i386, mips64el, mipsel, ppc64el, s390x
libgraphite2-dev | 1.3.14-1    | testing | amd64, arm64,
armel, armhf, i386, mips64el, mipsel, ppc64el, s390x
libgraphite2-dev | 1.3.14-1    | unstable    | amd64, arm64,
armel, armhf, i386, mips64el, mipsel, ppc64el, s390x

> There is no libgraphite2.a file, so it is not possible to compile statically
> against this library. 
Because upstream doesn't build one in their standard build and I didn't
bother to manually build it as in your patch ...
> See attached patch to solve this.
.. as I am not sure. Why would people want to statically build against

libgraphite2.a anyways?

> -- System Information:
> Debian Release: bullseye/sid
>   APT prefers focal-updates
>   APT policy: (500, 'focal-updates'), (500, 'focal-security'), (500, 
> 'focal'), (100, 'focal-backports')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386

Ah, this explains it. If you use Ubuntu please do some care to make a correct 
Debian bug report.


Regards,


Rene

Bug#994698: one more fix for armhf needed

[Rene Engelhard]

reopen 994698
thanks

Hi,


Am 20.09.21 um 00:00 schrieb Rene Engelhard:
> Am 19.09.21 um 17:28 schrieb Rene Engelhard:
>> Whereas LO builds with g++ 11 since 1:7.1.0~rc1-1 in general Rico pointed me 
>> to
>> https://git.launchpad.net/~libreoffice/ubuntu/+source/libreoffice/commit/?h=ubuntu-impish-7.2=d880a443cc0c49692acc457f24468715199f076e
>> which also needs to be done on Debian with g++ 11 on armhf (reproduced
>> on amdahl with 11.2.0-5).
> 
> Actually g++-11 11.2.0-7 fixed that... Will revert that patch (and use a
> proper build dependency).

I shouldn't do such stuff this late and tired. (Forgot to force
GCC_VERSION in my 11.2.0-7 attempt :/).

Patch still is needed.

Regards,

Rene

Bug#994698: [r...@debian.org: one more fix for armhf needed]

[Rene Engelhard]

Hi,

only appeared in the original bug, fwd...

Regards,

Rene

- Weitergeleitete Nachricht von Rene Engelhard  -

Date: Sun, 19 Sep 2021 17:28:52 +0200
From: Rene Engelhard 
To: 984...@bugs.debian.org, 984204-submit...@bugs.debian.org
Cc: cont...@bugs.debian.org
Subject: one more fix for armhf needed

severity 984204 important
clone 984204 -1
block 984204 by -1
retile -1 FTBFS with g++ 11 on armhf: Error: selected processor does not 
support `vpush {d0-d7}' in ARM mode 
tag -1 + pending
thanks

Hi,

Whereas LO builds with g++ 11 since 1:7.1.0~rc1-1 in general Rico pointed me to
https://git.launchpad.net/~libreoffice/ubuntu/+source/libreoffice/commit/?h=ubuntu-impish-7.2=d880a443cc0c49692acc457f24468715199f076e
which also needs to be done on Debian with g++ 11 on armhf (reproduced
on amdahl with 11.2.0-5).

Already added in git.

Regards,

Rene

- Ende weitergeleitete Nachricht -

Bug#984204: one more fix for armhf needed

[Rene Engelhard]

severity 984204 important
clone 984204 -1
block 984204 by -1
retile -1 FTBFS with g++ 11 on armhf: Error: selected processor does not 
support `vpush {d0-d7}' in ARM mode 
tag -1 + pending
thanks

Hi,

Whereas LO builds with g++ 11 since 1:7.1.0~rc1-1 in general Rico pointed me to
https://git.launchpad.net/~libreoffice/ubuntu/+source/libreoffice/commit/?h=ubuntu-impish-7.2=d880a443cc0c49692acc457f24468715199f076e
which also needs to be done on Debian with g++ 11 on armhf (reproduced
on amdahl with 11.2.0-5).

Already added in git.

Regards,

Rene

Bug#985867: reverted

[Rene Engelhard]

unarchive 985867
tag 985867 - patch
found 985867 1:7.2.1-1
thanks

Hi,

this was reverted. (There was no actual LTO usage anywyay ttbomk).

- It missed a chmod 755 so  that clang_wrapper was executable

  This was fixed in 1:7.2.0-3

- configure doesn't detect any clang and uses g++
  (cf.
  
https://buildd.debian.org/status/fetch.php?pkg=libreoffice=amd64=1%3A7.2.0-3%2Bb1=1630963567=0):

checking whether to build Skia... yes
checking for Clang... /<>/debian/usr/bin/clang / 
/<>/debian/usr/bin/clang++
clang: error: -E or -x required when input is from standard input
configure: WARNING: "" is too old or unrecognized, must be at least Clang 5.0.2
configure: WARNING: Clang compiler not found.

  (or - worse - fails directly if one actually wants to use clang as
  main compiler):

configure output:
[...]
checking for x86_64-linux-gnu-gcc... clang
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables... configure: error: in 
`/home/rene/Debian/Pakete/LibreOffice/libreoffice/libreoffice-7.2.0.4':
configure: error: cannot compute suffix of executables: cannot compile and link
See `config.log' for more details
Error running configure at ./autogen.sh line 322.
[...]

config.log:

configure:7725: checking whether the C compiler works
configure:7747: clang -g -O2 
-ffile-prefix-map=/home/rene/Debian/Pakete/LibreOffice/libreoffice/libreoffice-7.2.0.4=.
 -fstack-protector-strong -
Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -Wl,-z,relro 
conftest.c  >&5
configure:7751: $? = 0
configure:7801: result: yes
configure:7804: checking for C compiler default output file name
configure:7806: result: a.out
configure:7812: checking for suffix of executables
configure:7819: clang -o conftest -g -O2 
-ffile-prefix-map=/home/rene/Debian/Pakete/LibreOffice/libreoffice/libreoffice-7.2.0.4=.
 -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
-D_FORTIFY_SOURCE=2 -Wl,-z,relro conftest.c  >&5
clang: error: no such file or directory: 'conftest'
configure:7823: $? = 1
configure:7840: error: in 
`/home/rene/Debian/Pakete/LibreOffice/libreoffice/libreoffice-7.2.0.4':
configure:7842: error: cannot compute suffix of executables: cannot compile and 
link
See `config.log' for more details

Do you want to send a updated patch?

Regards,

Rene

Bug#994624: libreoffice fail to start with error undefined symbol: _ZNK11LanguageTag20getGlibcLocaleStringESt17basic_string_viewIDsSt11char_traitsIDsEE

[Rene Engelhard]

tag 994624 - moreinfo
retitle 994624 libreoffice fail to start with error undefined symbol:
_ZNK11LanguageTag20getGlibcLocaleStringESt17basic_string_viewIDsSt11char_traitsIDsEE
after installing 7.2.1-1 on testing
severity 994624 serious
thanks

Hi,

Am 19.09.21 um 11:11 schrieb Rene Engelhard:
> - I will try in a fresh sid amd64 VM

OK, did  3 tests:

- pure testing with 7.1.5-1 -> expectedly starts

- add unstable to sources.list and do apt install libreoffice to do a
partial update just with the dependencies LO specifies:

breaks with the message

- dist-upgrade to full sid

works again



Interesting..

But you still should have told that you did a partial upgrade.

Looks like some underly strict dependency...

Regards,

Rene

Bug#994624: libreoffice fail to start with error undefined symbol: _ZNK11LanguageTag20getGlibcLocaleStringESt17basic_string_viewIDsSt11char_traitsIDsEE

[Rene Engelhard]

reopen 994624

thanks


Hi,

Am 19.09.21 um 12:25 schrieb Rene Engelhard:
> OK, looking at a diff between 7.1.5 and 7.2.1 suggests that the UNO
> runtime got new LanguageTag-using functions so I did:
> - install testing
> - install libreoffice from sid
> -> run in to the error
> - install ure 7.2.0-2/uno-libs-private 7.2.0-2 (first version ever uploaded 
> to sid) from snapshot.debian.org
> -> works
>
> So the dependency on ure needs to be bumped. (to >= 1:7.2.0~). Will do.

This is actually worse...


-OUString LanguageTagImpl::getGlibcLocaleString() const
+OUString const & LanguageTagImpl::getGlibcLocaleString() const
@@ -1942,7 +1951,7 @@ OUString LanguageTagImpl::getGlibcLocaleString() const
-OUString LanguageTag::getGlibcLocaleString( const OUString & rEncoding
) const
+OUString LanguageTag::getGlibcLocaleString( std::u16string_view
rEncoding ) const

is the "offending" difference.


So with 7.1.5 from testing and ure from sid I get another error of the
same type:

$ libreoffice
/usr/lib/libreoffice/program/soffice.bin: symbol lookup error:
/usr/lib/libreoffice/program/libmergedlo.so: undefined symbol:
_ZNK11LanguageTag20getGlibcLocaleStringERKN3rtl8OUStringE


There's also a Breaks: needed...

(done in
https://salsa.debian.org/libreoffice-team/libreoffice/libreoffice/-/commit/655e85dc495f141324afce193185c900058782b5)


Regards,


Ren

Bug#994624: libreoffice fail to start with error undefined symbol: _ZNK11LanguageTag20getGlibcLocaleStringESt17basic_string_viewIDsSt11char_traitsIDsEE

[Rene Engelhard]

retitle 994624 libreoffice fail to start with error undefined symbol: 
_ZNK11LanguageTag20getGlibcLocaleStringESt17basic_string_viewIDsSt11char_traitsIDsEE
 with pre-7.2.0 ure
tag 994624 + confirmed
thanks

Hi,

Am 19.09.21 um 11:43 schrieb Rene Engelhard:
> - add unstable to sources.list and do apt install libreoffice to do a
> partial update just with the dependencies LO specifies:
>
> breaks with the message

OK, looking at a diff between 7.1.5 and 7.2.1 suggests that the UNO runtime got 
new LanguageTag-using functions so I did:

- install testing
- install libreoffice from sid
-> run in to the error
- install ure 7.2.0-2/uno-libs-private 7.2.0-2 (first version ever uploaded to 
sid) from snapshot.debian.org
-> works

So the dependency on ure needs to be bumped. (to >= 1:7.2.0~). Will do.

Regards,

Rene

Bug#994624: libreoffice fail to start with error undefined symbol: _ZNK11LanguageTag20getGlibcLocaleStringESt17basic_string_viewIDsSt11char_traitsIDsEE

[Rene Engelhard]

tag 994624 + moreinfo

thanks


Hi,

Am 18.09.21 um 22:40 schrieb Pirate Praveen:
> $ libreoffice
> /usr/lib/libreoffice/program/soffice.bin: symbol lookup error:
> /usr/lib/libreoffice/program/libmergedlo.so: undefined symbol:
> _ZNK11LanguageTag20getGlibcLocaleStringESt17basic_string_viewIDsSt11char_traitsIDsEE
>
You as DD should know that this is missing information. Like the
reportbug info (architecture, installed packages, etc).


Which architecture? Which libc version?


Besides that

- I don't believe that since
https://ci.debian.net/packages/libr/libreoffice/unstable/amd64/ all
pass, and they do gazillions of startups of LO.

- I will try in a fresh sid amd64 VM


Regards,


Rene

Bug#994445: Libreoffice suggests wrong KDE package

[Rene Engelhard]

Hi,

Am 16.09.21 um 11:03 schrieb Rene Engelhard:
> Though admittedly -plasma misses a Recommends: on libreoffice-kde5:
> rene@frodo:~$ apt-cache show libreoffice-plasma | grep Recomm
> rene@frodo:~$ apt-cache show libreoffice-gnome | grep Recomm
> Recommends: libreoffice-style-elementary, libreoffice-gtk3
>
>
> Will add  that one.

Obviously I meant -kf5 :)

(cf.
https://salsa.debian.org/libreoffice-team/libreoffice/libreoffice/-/commit/8aa042f967976eeb843e68e3ce8ec02d798036a6)

Regards,


Rene

Bug#994445: Libreoffice suggests wrong KDE package

[Rene Engelhard]

retitle 994445 missing Recommends on libreoffice-kf5

reassign 994445 libreoffice-plasma

severity 994445 minor

thanks


Hi,

Am 16.09.21 um 09:16 schrieb karl...@abwesend.de:

> Package: libreoffice
> Version: 1:7.0.4-4

(no Severity)
Sorry, no, IMHO this is a minor bug, not a normal one, but it will be changed
(will never happen in stable though)

> After installing the package "libreoffice-plasma" which was suggested by
> package "libreoffice" [1], Libreoffice looked pretty bad on KDE.
Of course, -plasma just contains stuff useful to KDE, not the KDEish UI.
As does -gnome, that one also doesn't contain the GTk3-ish UI.
> I had to look at the Debian Wiki [2] to find out that the proper package
> to install is "libreoffice-kde5".

That info is wrong (well, obsolete):

$ apt-cache show libreoffice-kde5
Package: libreoffice-kde5
Source: libreoffice
Version: 1:7.0.4-4
Installed-Size: 217
Maintainer: Debian LibreOffice Maintainers

Architecture: amd64
Depends: libreoffice-kf5, libreoffice-plasma
Description-en: transitional package for LibreOffice "KDE 5" integration
 LibreOffice is a full-featured office productivity suite that provides
 a near drop-in replacement for Microsoft(R) Office.
 .
 This package used to contain the "KDE 5" integration. It was split
 into -kf5 (KF5 UI plugin) and -plasma (some Plasma integration). This
 packsge can be safely removed once installed.
Description-md5: 9ba37e0af16899bba520effef300bdf2
Homepage: http://www.libreoffice.org
Tag: uitoolkit::gtk, uitoolkit::qt
Section: kde
Priority: optional
Filename: pool/main/libr/libreoffice/libreoffice-kde5_7.0.4-4_amd64.deb
Size: 199592
MD5sum: fe9172ba035c562af5002820fb726e9b
SHA256: a55cb848965d474f82d3c8e6a055f28f32e1d0e038be512a5de0aa37e57614fa

And libreoffice-kde5 thus doesn't exist anymore in testing and unstable.


The solution is to use and read package descriptions, not rely on maybe
out-of-date infos in wikis :)

>  Please change that suggestion on the
> "libreoffice" package.

[...]

[1] "Suggests: libreoffice-gnome | libreoffice-plasma"

No, that suggestion is for the desktop environment and completely correct.


What you might have wanted is libreoffice-kf5.

(libreoffice-kde5 just  happens to work because of said transitional
package.)


Though admittedly -plasma misses a Recommends: on libreoffice-kde5:

rene@frodo:~$ apt-cache show libreoffice-plasma | grep Recomm
rene@frodo:~$ apt-cache show libreoffice-gnome | grep Recomm
Recommends: libreoffice-style-elementary, libreoffice-gtk3


Will add  that one.


Regards,


Rene

Bug#993449: libreoffice-calc: Top level tool menu is missing text labels and icons for most buttons

[Rene Engelhard]

Hi,

Am 14.09.21 um 15:59 schrieb Rene Engelhard:
> b) removed the unreproducible tag already.

OK, actually I forgot the CC. (This happens if you do it when you
actually have more imprtant university stuff to do...)

Done manually now.


Regards,

Rene

Bug#993449: libreoffice-calc: Top level tool menu is missing text labels and icons for most buttons

[Rene Engelhard]

Hi,

Am 14.09.21 um 15:54 schrieb paul deg:
> Saying it's "not reproducible" is refusing to accept reality.

If you actually have read my mails you would have seen that I

a) acknowledged the problem (there's a easy workaround, though)

b) removed the unreproducible tag already.


Regards,


Rene

Bug#993449: libreoffice-calc: Top level tool menu is missing text labels and icons for most buttons

[Rene Engelhard]

Am 14.09.21 um 15:20 schrieb paul_deg:
> What you say makes 0 sense.

Helpful. Not.


I could have said that for you too, (besides that your "top menu" also
didn't make any sense at all given you mean "tool bar".)

I didn't, I tried to argue with examples. Like writing black on black.

(here it is that beige or whatever that is on Adwaitas default beige
background.)


> Anyone can choose this icon set, this is  what tweaks tool is for.

I didn't say otherwise. Of course one can. One can also just set a dark
normal UI theme in additon and be done,


I also didn't say this wasn't a problem. If I did the bug would be closed.

> And Libre office is the only app which has issues with it, likely
> because it's incompatible.

Maybe, because it's not a native gtk app (tries to look like it, but
also has own icons).


I still maintain that it would be trivial to also use a black background
and then this would be non-issue.

Regards,


Rene

Bug#993449: libreoffice-calc: Top level tool menu is missing text labels and icons for most buttons

[Rene Engelhard]

tag 993449 - unreproducible

thanks


Hi,

Am 14.09.21 um 02:29 schrieb paul deg:
> Still reproducible on my end. Make sure "icon style" in LibreOffice
> options/view is set to� "automatic", which is default. 

Or default in gnome tweaks.


> Then in Gnome tweaks select icon set as "breeze-dark".

True.


Thinking about it a bit more:


And why would anyone do that? That sounds like a unfortunate combination
to me but nothing one can do against.


If the breeze_dark icons assume (btw, in your subject you say "tool
menu", so you definitely mean "tool bar", I literally read it as "menu",
that's why I did the second screenshot...) a black background and do the
icons in the color which is used by adwaita in the background, what
can/should one do?

Just set both to breeze_dark? (or at least dark for the general UI)?

No one is saying any combination makes sense.


If you have a black paper, you also wouldn't complain to someone that
you can't actually read stuff you write witha black pen? Or light yellow
on white? Or ...


Regards,


Rene

Bug#993449: libreoffice-calc: Top level tool menu is missing text labels and icons for most buttons

[Rene Engelhard]

Am Mon, Sep 13, 2021 at 11:27:07AM +0200 schrieb Rene Engelhard:
> See screenshots. Looks OK.

And yes, even with Adwaita there is no icons in any menu.

The (needed) checkboxes as (as you see in my menu.png) also there.

So it's still unreproducible.
 
Regards,
 
Rene

Bug#993449: libreoffice-calc: Top level tool menu is missing text labels and icons for most buttons

[Rene Engelhard]

retitle 993449 libreoffice-calc: Top level tool menu is missing text
labels and icons for most buttons with breeze-dark theme
found 993449 1:7.1.5-2
thanks

[ sorry for the late answer, never appeared in my mbox, just saew it by
chance in the BTS logs ]

Hi,

Am Wed, Sep 01, 2021 at 11:58:54AM -0500 schrieb paul deg:
> "Great" attitude Rene, I must say, ever heard about "politeness"?

Not for soch bogus "critical" bugs. That is not a willy-nilly
categorization. Severities have rules.

And this defintely DOES NOT *BREAK THE WHOLE SYSTEM*.

I am trying to be polite if people actually show some care in what they
write. Which you obviously did not.

And that bugs shoud have content should be pretty obvious, shouldn't it?

> To  reproduce: just switch to "breeze-dark" style in Gnome using Gnome
> Tweaks tool, then start LibreOffice.

Aha, that is interesting to know. That should have been in the initial
report.

> A workaround is to force regular breeze icons in LibreOffice "options"
> instead of "automatic, which is default .

So it definitely is important only since with default it works.

> Same issue exists in the next version of LibreOffice in "testing".

Marking as such.

Regards,

Rene

Bug#993710: caveexpress: FTBFS with box2d 2.4: fatal error: Box2D/Box2D.h: No such file or directory

[Rene Engelhard]

Source: caveexpress
Version: 2.5.1-1
Severity: serious

Hi,

as I said in my post to -release caveexpress doesn't build anymore with the 
newly
unoddinated(!) upload of box2d 2.4:

[...]

[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#993449: libreoffice-calc: Top level tool menu is missing text labels and icons for most buttons

[Rene Engelhard]

severity 993449 important
tag 993449 + moreinfo
tag 993449 + unreproducible
thanks

Hi,

Am Wed, Sep 01, 2021 at 09:56:22AM -0500 schrieb pavel:
> Package: libreoffice-calc
> Version: 1:7.0.4-4
> Severity: critical
> Justification: breaks the whole system

Bulls*.

How does it break booting? How does it break other parts of
the system?

If at all, it'd be "grave".

Read the bug definitions and don't submit overinflated bug reports.

> X-Debbugs-Cc: paul_...@yahoo.com
> 
> Dear Maintainer,
> 
> *** Reporter, please consider answering these questions, where appropriate ***
> 
>* What led up to the situation?
>* What exactly did you do (or not do) that was effective (or
>  ineffective)?
>* What was the outcome of this action?
>* What outcome did you expect instead?
> 
> *** End of the template - remove these template lines ***

Yes. Do. That's not there just for fun.
No text here is no real good sign of anything.

Anyways, your mail subject says

 Subject: Re: Bug#993449: libreoffice-calc: Top level tool menu is missing
  text labels and icons for most buttons

You should haver added some explanation here

In any case:

Oh, surprise. Works here fine. (and yes, I tried with gen(eric), gtk3,
qt5 and kde5).

So this is even unreproducible.

Regards,

Rene

Bug#992779: libreoffice-gnome: conflicts with libreoffice-gtk3

[Rene Engelhard]

severity 992779 serious

found 992779 1:7.2.0-2

notfound 992779 1:7.1.5-2

tag 992779 + confirmed

thanks


Hi,

Am 23.08.21 um 12:31 schrieb Nicolas Patrois:
> Package: libreoffice-gnome
> Version: 1:7.1.5-2

Oh, my. obviously not. If at all the bug is in the new package not
declaring the correct fields.

Please some care (and if reportbug gives you that it is _your_ job to
fix that version field.)

> libreoffice-gnome tries to overwrite a file
> (/usr/lib/libreoffice/program/liblosessioninstalllo.so) that already belongs 
> to
> libreoffice-gtk3.


Sigh,  that nonsensical file again. It's not LOs job to install
*anything* and this file should ideally not even be installed in any way...

Will have a look.. I guess I'll do a quick-gap solution until I decide
what I do with that file...


Regards,


Rene

Bug#992364: libreoffice: Libreoffice fails to start - can't cd to ../lib/libreoffice/program

[Rene Engelhard]

Hi,

last note.

Am 18.08.21 um 07:56 schrieb Rene Engelhard:
>> "/usr/local/bin/libreoffice: 52: cd: can't cd to ../lib/libreoffice/program"
> And obviously nothing in this package contains any
> 
> /usr/local/bin/libreoffice

In fact, anything in /usr/local is a policy violation per se.

9.1.2. Site-specific programs
As mandated by the FHS, packages must not place any files in /usr/local,
either by putting them in the file system archive to be unpacked by dpkg
or by manipulating them in their maintainer scripts.

And lintian also errors out for it (no matches in the arhive, as expected):
https://lintian.debian.org/tags/file-in-usr-local

At the /usr/local you would have already seen that this is notihing
which has to do with the package itself (except when you copied
/usr/bin/libreoffice to /usr/local/bin/libreoffice) so no reason to
report a bug at all - more a reason to fix your admin error.

> Did you put one there yourself once? You are are not supposed to copy
> stuff around...

This still holds.

Regards,

Rene

Bug#992364: libreoffice: Libreoffice fails to start - can't cd to ../lib/libreoffice/program

[Rene Engelhard]

Hi,

Am 18.08.21 um 07:56 schrieb Rene Engelhard:
> Did you put one there yourself once? You are are not supposed to copy
> stuff around...

And this fails because it expects to be in /usr (where it's supposed to
be) and then does that cd which works becazse LO is in
/usr/lib/libreoffice/program.

This is a startup shell script, not a simple binary (which you shouldn't
copy around either), which knows  the LO structure (for various reasons,
LO is a bunch of libs basically and  the "soffice" binary is a small
thing around it. Any stuff in LO has expectations of where its stuff is
which should not be changed  because it then breaks stuff unless there
is appropriate changes/workarounds).

In this case, /usr/local/bin/libreoffice will not work. Maybe when you
do cd ../../lib/libreoffice/program, but I wouldn't be so sure.

If you copied it yourself - why?

Regards,


Rene

Bug#973517: Fwd: Accepted libreoffice 1:7.1.5-1 (source) into unstable

[Rene Engelhard]

severity 973517 serious

thanks


Hi,


This has now happened, see below.


Regards,


Rene



 Weitergeleitete Nachricht 
Betreff:     Accepted libreoffice 1:7.1.5-1 (source) into unstable
Weitersenden-Datum:     Sun, 15 Aug 2021 07:04:03 + (UTC)
Weitersenden-Von:     debian-devel-chan...@lists.debian.org
Datum:     Sun, 15 Aug 2021 07:03:54 +
Von:     Debian FTP Masters 
Antwort an:     debian-de...@lists.debian.org
An:     debian-devel-chan...@lists.debian.org



Format: 1.8
Date: Sat, 14 Aug 2021 11:26:09 +
Source: libreoffice
Architecture: source
Version: 1:7.1.5-1
Distribution: unstable
Urgency: medium
Maintainer: Debian LibreOffice Maintainers

Changed-By: Rene Engelhard 
Changes:
libreoffice (1:7.1.5-1) unstable; urgency=medium
.
* "New" upstream release
.
* upload to unstable
Checksums-Sha1:
a3d30e3388fae6cc641715276abcd8efb26f584d 30638 libreoffice_7.1.5-1.dsc
aba19786280de076ceda78fb0f7c0822c1ee51ae 04596
libreoffice_7.1.5.orig-helpcontent2.tar.xz
5088b58e17f229c190f0955a2c0db281d28775d7 186102268
libreoffice_7.1.5.orig-translations.tar.xz
712834480f3e1537edaf95a9512f8889e05242e2 244350068
libreoffice_7.1.5.orig.tar.xz
716171a2afaf5f79e037340c92b915deb7f172fb 833
libreoffice_7.1.5.orig.tar.xz.asc
13c7e0ccdb69f51387dd7ac468f4f0f5253c8d8c 21514968
libreoffice_7.1.5-1.debian.tar.xz
2a035f88c7f0f8b09c082c479ea102728e4fd91c 33568
libreoffice_7.1.5-1_source.buildinfo
Checksums-Sha256:
deb1e5f7752ccc328bf62823969591fa4aa252dce9f847a878f054feb49538af 30638
libreoffice_7.1.5-1.dsc
e5ba6a610d3583590e8f9b1deccfdfbc8ab82e9eef64c52b8d07594259150621
04596 libreoffice_7.1.5.orig-helpcontent2.tar.xz
b4f188b12eb8cb49530a32501c8806d360996bf7f384e99e553d8d8118e1960b
186102268 libreoffice_7.1.5.orig-translations.tar.xz
aeaf30367665bdfdcf780d2b28e304352255de778db41d32d12cd77d5b2385ce
244350068 libreoffice_7.1.5.orig.tar.xz
e6bdf26e0791e4c8b41640b1578bf316f7c548e02c99bbc9a03a02e9d9675cce 833
libreoffice_7.1.5.orig.tar.xz.asc
792d439a169cd6d406b440980bd81b553398aadc880b957a9fd30be8f3f45956
21514968 libreoffice_7.1.5-1.debian.tar.xz
be3f30db125138c5b933e541aa9ae5e2e3a5608e206a51effb542bc2477ca609 33568
libreoffice_7.1.5-1_source.buildinfo
Files:
90db43709910798716eb28175d22da54 30638 editors optional
libreoffice_7.1.5-1.dsc
c68d1d18902b214134f4a72111a05dbc 04596 editors optional
libreoffice_7.1.5.orig-helpcontent2.tar.xz
b18e8d18fa4e0e5ffdcede1d04569fbd 186102268 editors optional
libreoffice_7.1.5.orig-translations.tar.xz
c713b9417769650c3c2007352a7bf3a8 244350068 editors optional
libreoffice_7.1.5.orig.tar.xz
8d12e6bb3596754c85495ab8ecc2d30a 833 editors optional
libreoffice_7.1.5.orig.tar.xz.asc
72f1948d3362de61d607380e25c65bb0 21514968 editors optional
libreoffice_7.1.5-1.debian.tar.xz
77fb3819485cda43093b7f8b12d83fce 33568 editors optional
libreoffice_7.1.5-1_source.buildinfo

Bug#934678: Processed: reopen bug #934678

[Rene Engelhard]

notfound 934678 7.0.4.2

thanks


Am 17.06.21 um 16:21 schrieb Debian Bug Tracking System:
>> found  #934678 7.0.4.2

And this is smply wrong, there is no  7.0.4.2 in Debian context.
Version: is the *package* version here.

(and it's not needed since the  version tracking clearly knows 1:7.0.4-4
is affected. That is not changed by saying that 1:7.2.0~beta1-1 fixes it)

Regards.


Rene

Bug#988906: unblock: libreoffice/1:7.0.4-4

[Rene Engelhard]

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#985297: libreoffice-common: do not use dir_to_symlink for /usr/lib/libreoffice/share/registry

[Rene Engelhard]

Hi,

Am 30.04.21 um 16:23 schrieb Andreas Beckmann:
> I've been experimenting a lot to fix this bug.
Thanks very much.
> 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.
Cool, thanks.
> The attached patch does only patch debian/control.in, please regenerate
> debian/control as this caused a lot of noise (I did nocheck builds).
Applied.
> It also contains adding some weird symbols with symbol version GLIBCXX_3.4
> that looks weird, because libreoffice should not provide symbols with
> such a version. This could also be an artefact of how I did build the
> packages. Please decide what should happen to them.

Ignore them.I would say it's a gcc detail. The only thing I maintain in
the .symbols files is LOs own public versions.


Regards,


Rene

Bug#987552: FTBFS caused by imagemagick

[Rene Engelhard]

block 987552 by 987504

thanks


Hi,

Am 25.04.21 um 15:05 schrieb Chris Hofstaedtler:
> Caused by #987504, see that bug for further details.

Then imagemagick should be fixed. I mean, come on, it's simple image
convert...


Regards,


Rene

Bug#986876: regression: libreoffice can't open filenames containing spaces

[Rene Engelhard]

severity 986876 minor

retitle 986876 libreoffice can't open filenames containing spaces if not
properly quoted if started from  terminal

thanks


Hi,

Am 13.04.21 um 12:11 schrieb Sander van Grieken:
> Package: libreoffice
> Version: 1:7.0.4-3
> Severity: important

No, see below. I am not even sure this is a bug at all - if at all it's
a user error.

> When attempting to open a file containing spaces (in a path that does not
> contain any spaces), libreoffice doesn't open but instead shows a error 
popup
> for each of the filename parts separated by spaces, e.g.
>
> /home/user/documents/file containing spaces.ods
>
> .. will show three popups:
> /file does not exist.
> /containing does not exist.
> paces.ods does not exist.

Maybe. But if it worked so far I'd argue it was just by luck.


$ localc This\ is\ a\ test.ods

works as expected.

$ localc This

completes it to above and it works.


As does opening the document e.g. via nautilus.


> I also tried adding quotes to the .desktop file (to no avail)


$ localc "This is a test.ods"

and

$ localc 'This is a test.ods'

both work as expected., though on the console.


If you call it right it works, so I'd argue it's just minor - if it is a
bug at all.


Regards,


Rene

Bug#986418: libreoffice-impress: Impress cannot reduce table row size

[Rene Engelhard]

close 986418 1:7.1.1~rc2-1

thanks

Hi,

Am 06.04.21 um 22:55 schrieb Drew Parsons:
> Anyhow, I converted the "close" tag to "fixed" in 1:7.1.1~rc2-1.  If
> you think this bug really does need to be closed and dropped, then I
> won't reopen it again.
>
"closed" is correct. The same would have happened in a normal upload.

The fixed version is available (although admittedly only in
experimental) and the version tracking clearly *does know* 7.0.4 is
affected.

Regards,


Rene

Bug#986418: libreoffice-impress: Impress cannot reduce table row size

[Rene Engelhard]

tag 986418 + fixed-upstream

tag 986418 + upstream

forwarded 986418 
https://bugs.documentfoundation.org/show_bug.cgi?id=139511

close 986418 1:7.1.1~rc2-1

thanks


Hi,

Am 05.04.21 um 16:45 schrieb Drew Parsons:
> Package: libreoffice-impress
> Version: 1:7.0.4-3
> Severity: important
> Control: forwarded -1 
> https://bugs.documentfoundation.org/show_bug.cgi?id=139511
> Control: tags -1 + patch bullseye
>
> LibreOffice (7.0.4) cannot reduce the size of table rows in Impress.
>
> Apparently this is a known bug, fixed upstream and fixed in 7.1.1,
> https://bugs.documentfoundation.org/show_bug.cgi?id=139511
Or in 7.0.5...
> It's quite a serious bug in terms of usability of this part of the
> package.  Can the patch be applied to 7.0.4 in unstable targetted for
> inclusion in the bullseye stable release?

I am not sure. Where do you draw the line? But given I probably need to
work around dpkg not working as expected anyway, maybe.

Marking the metadata., though (thus also "closing" it for 7.1.1)


Regards,


Rene

Bug#985867: filter out GCC's lto flags for the skia build

[Rene Engelhard]

severity 985867  wishlist

thanks


Hi,

Am 25.03.21 um 08:59 schrieb Matthias Klose:
> When building LO with lto turned on (https://wiki.debian.org/ToolChain/LTO),
> the build fails, because one module (skia) is still built with clang, 
> apparently
> for performance reasons. I didn't check if that's still needed for recent
> compiler versions.

No idea either, I just use it to not derivate from upstream unneccessarily.

> So just don't use the lto flags when building the skia module. The build 
> system
> already has a macro for that for cflags (gb_FilterOutClangCFLAGS), but is
> lacking one for ldflags, and these targets seem to be autogenerated. I didn't
> look into filtering this, 

Yeah, I gave up somewhen, too

> and provided a wrapper for clang/clang++ instead.

OK.


Will add to git.


Regards,


Rene

Bug#985401: dpkg: libreoffice buster->bullseye upgrade failures

[Rene Engelhard]

Hi again,

Am 18.03.21 um 06:53 schrieb Rene Engelhard:
> It would be helpful if you actually did your homework. There already was
> 985297 so you now caused a bogus addditional RC bug.
> 
> That bug even was marked as blocked by the dpkg bug so being careful
> when reassigning RC bugs would actually be of help.
> 
> Now I have two of them. (Yes, I know about merge but still it is wrong
> to reassign llike this at all.)

Sorry for my tone this morning, but waking up with a RC bug more for
this wasn't actually making me happy in any way.

>>>   Preparing to unpack .../3-libreoffice-common_1%3a7.0.4-3_all.deb ...
>>>   dpkg-maintscript-helper: error: file 
>>> '/usr/lib/libreoffice/share/registry/writer.xcd' not owned by package 
>>> 'libreoffice-common:all'
>>>   dpkg-maintscript-helper: error: directory 
>>> '/usr/lib/libreoffice/share/registry' contains files not owned by package 
>>> libreoffice-common:all, cannot switch to symlink
>>>   dpkg: error processing archive 
>>> /tmp/apt-dpkg-install-sERX6l/3-libreoffice-common_1%3a7.0.4-3_all.deb 
>>> (--unpack):
>>>new libreoffice-common package pre-installation script subprocess 
>>> returned error exit status 1
>>>   rmdir: failed to remove '/var/lib/libreoffice/program/': No such file or 
>>> directory
>>>   rmdir: failed to remove '/var/lib/libreoffice': No such file or directory
>> The libreoffice-common preinst maintainer script fails, so I'd expect
>> the installation for the package gets aborted and the conflictor does
>> not get removed after this, and before processing the next archive.
> 
> It fails because of
> 
>   dpkg-maintscript-helper: error: file 
> '/usr/lib/libreoffice/share/registry/writer.xcd' not owned by package 
> 'libreoffice-common:all'
>   dpkg-maintscript-helper: error: directory 
> '/usr/lib/libreoffice/share/registry' contains files not owned by package 
> libreoffice-common:all, cannot switch to symlink
> 
> which is dpkg-maintscript-helpers domain.

Actually I pondered filing a bug back then (wishlist) when I first saw
this because I think dpkg should trust maintainers to do the right thing
if they used dir_to_symlink and the ownership of the file  changes.
(That would also have saved the Conflicts)

Is there a way to do  that? Or some way to force it?

Then I didn't actually do it and "just" added the Conflicts:

(The symlink is only needed because of LO not honouring their own
configuration so otherwise the config is not found - see #972043 and
#969653)

Regards,

Rene

Bug#985297: libreoffice-common: needs Conflicts against all packages shipping files in /usr/lib/libreoffice/share/registry

[Rene Engelhard]

Am 18.03.21 um 08:32 schrieb Andreas Beckmann:
> a clean minimal buster
>
> apt-get install libreoffice-writer # without --install-recommends enabled
>
> or
>
> apt-get install libreoffice-calc # happens both with and without
> --install-recommends enabled
>
Hrm. Indeed.


Regards,


Rene

Bug#985401: dpkg: libreoffice buster->bullseye upgrade failures

[Rene Engelhard]

reassign 985401 dpkg

thanks


Hi Guillem,

Am 18.03.21 um 00:02 schrieb Guillem Jover:
> Control: reassign -1 libreoffice-common 1:7.0.4-3

It would be helpful if you actually did your homework. There already was
985297 so you now caused a bogus addditional RC bug.

That bug even was marked as blocked by the dpkg bug so being careful
when reassigning RC bugs would actually be of help.

Now I have two of them. (Yes, I know about merge but still it is wrong
to reassign llike this at all.)

dpkg detects there's a Conflicts involved during the unpack and queues
> it for later removal. (Although that removal is then silent anyway, which
> seems confusing, so ideally dpkg should probably print something like we
> do with the de-configuring.)

Want a bug for this?

>>   Preparing to unpack .../3-libreoffice-common_1%3a7.0.4-3_all.deb ...
>>   dpkg-maintscript-helper: error: file 
>> '/usr/lib/libreoffice/share/registry/writer.xcd' not owned by package 
>> 'libreoffice-common:all'
>>   dpkg-maintscript-helper: error: directory 
>> '/usr/lib/libreoffice/share/registry' contains files not owned by package 
>> libreoffice-common:all, cannot switch to symlink
>>   dpkg: error processing archive 
>> /tmp/apt-dpkg-install-sERX6l/3-libreoffice-common_1%3a7.0.4-3_all.deb 
>> (--unpack):
>>new libreoffice-common package pre-installation script subprocess 
>> returned error exit status 1
>>   rmdir: failed to remove '/var/lib/libreoffice/program/': No such file or 
>> directory
>>   rmdir: failed to remove '/var/lib/libreoffice': No such file or directory
> The libreoffice-common preinst maintainer script fails, so I'd expect
> the installation for the package gets aborted and the conflictor does
> not get removed after this, and before processing the next archive.

It fails because of

  dpkg-maintscript-helper: error: file 
'/usr/lib/libreoffice/share/registry/writer.xcd' not owned by package 
'libreoffice-common:all'
  dpkg-maintscript-helper: error: directory 
'/usr/lib/libreoffice/share/registry' contains files not owned by package 
libreoffice-common:all, cannot switch to symlink

which is dpkg-maintscript-helpers domain.

>>   Selecting previously unselected package libreoffice-writer.
>>   dpkg: considering deconfiguration of libreoffice-common, which would be 
>> broken by installation of libreoffice-writer ...
>>   dpkg: yes, will deconfigure libreoffice-common (broken by 
>> libreoffice-writer)
>>   Preparing to unpack .../4-libreoffice-writer_1%3a7.0.4-3_amd64.deb ...
>>   De-configuring libreoffice-common (1:6.1.5-3+deb10u7) ...
>>   Unpacking libreoffice-writer (1:7.0.4-3) over (1:6.1.5-3+deb10u7) ...
>>   Replacing files in old package libreoffice-common (1:6.1.5-3+deb10u7) ...
>>   Preparing to unpack .../5-libxmlsec1_1.2.31-1_amd64.deb ...
>>   Unpacking libxmlsec1:amd64 (1.2.31-1) over (1.2.27-2) ...
>>   Preparing to unpack .../6-libreoffice-base-core_1%3a7.0.4-3_amd64.deb ...
>>   Unpacking libreoffice-base-core (1:7.0.4-3) over (1:6.1.5-3+deb10u7) ...
>>   Errors were encountered while processing:
>>/tmp/apt-dpkg-install-sERX6l/3-libreoffice-common_1%3a7.0.4-3_all.deb
>>
>> So is dpkg going to remove libreoffice-writer or not?
> It would if the maintscript would not have failed.
It fails because of a bug in dpkg.
>> It says both and does 
>> not remove it, causing dpkg-maintscript-helper to fail since
>> /usr/lib/libreoffice/share/registry is not empty before dir_to_symlink
>> is run. There should be enough Conflicts to ensure all packages previously
>> shipping files there are removed or upgraded.
> This would be an incorrect assumption from the package, policy
> describes how Conflicts interact during upgrades in §6.6. Notice
> there the conflictors are only removed in step 13, the last one.

How is dir_to_symlink working in these cases then?


No, I am not going to add hand-crafted stuff this late in the release
cycle for something which is unreproducible here anyway.


Regards,


Rene

Bug#787080: Bug#894119: libreoffice: Please add libreoffice-online to the debian repository.

[Rene Engelhard]

Hi,

Am 16.03.21 um 22:02 schrieb Adi Kriegisch:
> thank you very much for the hard work you've put in packaging libreoffice
> online. Starting from your salsa repo[1] I was able to successfully build
> loolwsd and loleaflet packages with the libreoffice packages from
> buster-backports. There were, however, some issues with the unit tests.
> After trying to investigate some of the issues, I decided to skip the test
> by adding an empty override_dh_auto_test target.

Yeah, that one is a mess upstream:

- unit tests need debug

- tests need write permissions in the LO directory (which they of course
don't have in /usr/lib/libreoffice)

...


> Is there any reason why you use loolwsd's init script to configure it
> instead of setting the defaults in /etc/loolwsd/loolwsd.xml? With the
> current init script this does not work.

That part wasn't updated for some time, I wouldn't be surprised if it broke.

/etc/default is a well-known location for environment variables needed
by init scripts, though.


That said, for init script I'd stay as close as with upstream as
possible since maintaining an initi script is a PITA.

(People ideally should use systemd and the systemd unit anyway but init
scripts still should be shipped if feasible.)


But MRs (or patches if you don't have an account on salsa) welcome.

> I very much hope, you're going to continue your excellent work and
> libreoffice online hits the debian archive any time in a not too distant
> future! ;-)

If someone sorts out the JS mess and packages the modules (and keeps the
chain uptodate) ;-)

Then we just need to figure out the test mess (maybe not run them during
the build at all indeed and make it a

"needs-root breaks-testbed" autopkgtest. One should probably add a
autopkgtest anyway.)


Regards,


Rene

Bug#985297: libreoffice-common: needs Conflicts against all packages shipping files in /usr/lib/libreoffice/share/registry

[Rene Engelhard]

tag 985297 + moreinfo

tag 985297 + unreproducible

thanks


Hi,

Am 15.03.21 um 15:11 schrieb Andreas Beckmann:
> during a test with piuparts I noticed your package fails to upgrade from
> 'buster'.


In what scenario?

- a clean buster debootstrap + apt install libreoffice

- a clean buster debootstrap + apt install task-desktop task-german-desktop

- a clean buster debootstrap + apt install libreoffice-writer


all upgrade fine in "quick tests"[1]. (if it matters apt dist-upgrade)


> In this complicated upgrade case I don't see a solution to get
> dpkg-maintscript-helper dir_to_symlink to work properly ...

dpkg-maintscript-helper exists for cases like this. If it fails to do
what it does, isn't it a dpkg-maintscript-helper  bug?


> Therefore I'd suggest to not use dir_to_symlink here ... but to
> fixup the link in postinst configure:
>
> if [ ! -L /usr/lib/libreoffice/share/registry ]; then
>   if [ -d /usr/lib/libreoffice/share/registry ]; then
>   # this will fail if the directory is not yet empty
>   rmdir /usr/lib/libreoffice/share/registry
>   fi
>   ln -s /etc/libreoffice/registry /usr/lib/libreoffice/share/registry
> fi

I should really work around a dpkg bug in all those maintainer scripts
now in hard freeze?


Regards,


Rene


[1] don't really have time, need to prepare for exams next week...

Bug#984790: buster-pu: package libreoffice/1:6.1.5-3+deb10u7

[Rene Engelhard]

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#982274: usr.lib.libreoffice.program.soffice.bin: temporary files are not allowed due to length change

[Rene Engelhard]

Hi,

Am 09.03.21 um 19:27 schrieb Vincas Dargis:
> Changing rule into this:
>>>
>>> owner @{libo_user_dirs}/{,**/}lu?{,?,??}.tmp rwk, #Temporary
>>> file used when saving
>>>
>>> Did the trick (needed 9 symbol variant).
>>
>> As was done.
>>
>>
>> If you would actually have read the bug you would have seen that.
>
> I've looked at the
> https://salsa.debian.org/libreoffice-team/libreoffice/libreoffice/-/commit/03ba395bbe21154efc8a05dfbb9f7c16946eb4d2
> diff linked in one of the posts and I see 11 question marks, not 9.
>
Hmm, indeed. My bad.

That means we need to do some distinction like you suggested? The
original report just said basically "works if I add another digit", so 
that was what I did :-)


>> No one claimed this was fixed in 7.0.4.
>>
>> 7.0.x is in freeze. (It is in git for 7.0.x though should  there ever be
>> an  upload,)
>
>
> So this means that's it, profile will be defunct as users will not be
> able to save on Bullseye with profile enabled? :(
>
Jup, unfortunately.

> Complain-by-default is really bad policy, is there a hope to change
> that (having it without complain mode, but with "disabled" symlink)?

Personal opinion: I actually consider "ship a profile disabled" even
worse than "complain" since stuff won't even be seen. As of now you see
ALLOWED in  the logs at least.


Regards,


Rene

Bug#982274: usr.lib.libreoffice.program.soffice.bin: temporary files are not allowed due to length change

[Rene Engelhard]

Hi,

for avoidance of doubt...

Am 08.03.21 um 20:51 schrieb Rene Engelhard:
>> type=AVC msg=audit(1615225628.771:1363): apparmor="DENIED"
>> operation="mknod" profile="libreoffice-soffice"
>> name="/home/vincas/Dokumentai/lu4638vdjw1.tmp" pid=4638
>> comm="soffice.bin" requested_mask="c" denied_mask="c" fsuid=1000
>> ouid=1000FSUID="vincas" OUID="vincas"
>>
> Just because you enable the profile.

"Set the profile to enforcing" (from complain) I mean.

Regards,

Rene

Bug#984790: buster-pu: package libreoffice/1:6.1.5-3+deb10u7

[Rene Engelhard]

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

Bug#984703: libreoffice-calc: LibreOffice Calc executes code from current dir (encodings.py) when opening a .csv

[Rene Engelhard]

Hi again,

Am 07.03.21 um 23:08 schrieb Rene Engelhard:
> Am 07.03.21 um 22:45 schrieb Milko Krachounov:
>> After some additional testing, checking my environment and inspecting pyuno/
>> source/loader/pyuno_loader.cxx, I want to amend the report, particularly 
>> about 
>> 7.0.4 which is not affected (kind of).
> 
> Interestingly, in discussion on #debian-devel it is said that it does :/
> 
> See below.
[...]

OK, some more discussion sheds some more light on it and would explain
it. From #debian-devel again:

23:10 < _jwilk> OK, I kinda reproduced in buster without setting
PYTHONPATH myself. It doesn't crash for me, but it can't open the CSV file.
23:11 < _jwilk> I had to install libreoffice-lightproof-pt-br to trigger
the bug.
23:13 < _jwilk> So, yay, mystery solved?
23:14 < _rene_> on sid?
23:14 < _rene_> ah, on buster. yes, probably.
23:15 < _rene_> but according to the submitter and the upstream bug it
does not happen on 7.0.x
23:15 < _rene_> guess I need to fire up a buster vm
23:15 < _rene_> (and probably backport the upstream fix to buster. *sigh*)
23:16 < _rene_> yeah, libreoffice-lightproof-* is python. but I have
libreoffice-lightproof-en installed, too
23:16 < bunk> libreoffice-lightproof-en makes it reproducible for me on
buster
23:17 < _rene_> gah. even on my testing, indeed
23:17 < _rene_> no idea what I tested  before, probably I didn't do
PYTHONPATH=.
23:17 < _rene_> ok, so it boils down to
23:18 < _rene_> a) buster is affected without interaction (-> bad)
23:18 < _rene_> b) testing/sid is when setting PYTHONPATH=. (-> not
ideal,  but one shouldn't do so(tm))
23:21 < _rene_> thus this is something one needs to fix for buster, for
testing/sid it's "user error"
23:21  * _jwilk nods.
23:22 < bunk> I see some similarities between a) and
https://security-tracker.debian.org/tracker/CVE-2016-1238
23:22 < _rene_> indeed

@Salvatore: Want it done via DSA?

Regards,


Rene

Bug#984703: libreoffice-calc: LibreOffice Calc executes code from current dir (encodings.py) when opening a .csv

[Rene Engelhard]

forwarded 984703 https://bugs.documentfoundation.org/show_bug.cgi?id=121384

thanks


Hi,

Am 07.03.21 um 22:45 schrieb Milko Krachounov:
> After some additional testing, checking my environment and inspecting pyuno/
> source/loader/pyuno_loader.cxx, I want to amend the report, particularly 
> about 
> 7.0.4 which is not affected (kind of).

Interestingly, in discussion on #debian-devel it is said that it does :/

See below.


> First, I wonder if someone reproduces this on 1:6.1.5-3+deb10u6 (if nobody 
> does, I may whip up a VM to exclude other factors next Sunday).
Can try, too. My normal system is normally a stable but was already
upgraded to bullseye, though ("eat your own dogfood") due to the freeze.
> Indeed, however, on 1:7.0.4~rc2-1~bpo10+2 the issue is *NOT* reproducible (at 
> least with the given steps, see below), and was only happening entirely due 
> to 
> a local misconfiguration, as I had a trailing colon inside PYTHONPATH. That 
> causes Python 3 to crash with that error. My deepest apologies for polluting 
> the report with the wrong information about 7.0.4.
> However, I can still reproduce this on 6.1.5, and changing absolutely nothing 
> in the environment, including deletion of ~/.config/libreoffice does not seem 
> to stop it, and there is no PYTHONPATH set in any form. I also noticed that 

Yeah, LO does itself.

$ grep -r PYTHONPATH /usr/lib/libreoffice/*
/usr/lib/libreoffice/program/unopkg:export
PYTHONPATH="/usr/lib/libreoffice/program"
grep: /usr/lib/libreoffice/program/libpythonloaderlo.so:
Übereinstimmungen in Binärdatei
/usr/lib/libreoffice/program/pythonloader.unorc:PYUNO_LOADER_PYTHONPATH=$ORIGIN
/usr/lib/libreoffice/program/pythonloader.unorc:PYTHONPATH=$PYTHONHOME
$PYTHONHOME/site-packages $PYTHONHOME/lib-dynload $PYTHONHOME/lib-tk $ORIGIN

$

The latter is for scripts via python3-uno though.

> pyuno/source/loader/pyuno_loader.cxx from the buster source does add exactly 
> such trailing colon (an issue that has been explicitly fixed in 7.0.4, so 
> only 
> Buster is affected):
>
> bufPYTHONPATH.append( systemPath );
> bufPYTHONPATH.append( static_cast(SAL_PATHSEPARATOR) );
>
> I see the code for buster-backports (and presumably bullseye) has been 
> modified to not leave either trailing colons or colons surrounding an empty 
> string by adding three explicit checks (except for one case, which threw off 
> my testing):
>
> if (!systemPath.isEmpty())
> {
> if (bAppendSep)
> 
> bufPYTHONPATH.append(static_cast(SAL_PATHSEPARATOR));
> bufPYTHONPATH.append(systemPath);
> bAppendSep = true;
> }
> 
> const char * oldEnv = getenv( "PYTHONPATH");
> if( oldEnv )
> {
> if (bAppendSep)
> bufPYTHONPATH.append( static_cast(SAL_PATHSEPARATOR) 
> );
> bufPYTHONPATH.append( OUString(oldEnv, strlen(oldEnv), 
> osl_getThreadTextEncoding()) );
> }

Yes, this looks like
https://cgit.freedesktop.org/libreoffice/core/commit/?id=327153471ae38abe90463f6272e00aaa996c5ba3
and thus https://bugs.documentfoundation.org/show_bug.cgi?id=121384
(which is filed for writer and not calc, but...)

> P.S. Yeah, LibreOffice doesn't touch encodings.py. The error is produced by 
> Python during initialisation as it tries to determine the locale encoding, so 
> it happens before any external Python code is executed, and only happens if 
> something injects the local directory or an empty string in PYTHONPATH.

Yeah,  that was told to me on #debian-devel, too:

22:14 < olly[m]1> seems potentially problematic if PYTHONPATH is
honoured here (since it could find an entirely unrelated encodings.py on
PYTHONPATH),
  though not really RC or a security bug AFAICS
22:16 < _rene_> the question also is what calls encodings.py at all
22:17 < _rene_> since LO itself definitely does not

22:22 < _jwilk> Python itself loads it: https://paste.debian.net/1188328


[ content:

$ echo boom > encodings.py
$ export PYTHONPATH=/opt/moo:$PYTHONPATH   # oops, if PYTHONPATH is
empty, this adds cwd
$ python3
Fatal Python error: initfsencoding: Unable to get the locale encoding
Traceback (most recent call last):
  File "/home/jwilk/encodings.py", line 1, in 
NameError: name 'boom' is not defined
Aborted ]


which would support your report. Though I still don't see it.


22:33 < _rene_> and when?
22:34 < _rene_> since PYTHONPATH=. localc test.csv still doesn't load it
22:34 < _rene_> Fatal Python error: initfsencoding: Unable to get the
locale encoding
22:34 < _rene_> only then?
22:34 < _rene_> whatever that means
22:36 < _rene_> Hmm, OK, I do get an error with LANG=en_US PYTHONPATH=.
localc test.csv
22:36 < _rene_> but nothing on the console, though
22:37 < _rene_> ah, LANG=en_US in ~/äöü is not a good idea
22:37 < _rene_> still nothing pythonish, though

22:39 < _jwilk> It does crash here: https://paste.debian.net/1188332

[ content:

$echoboom > encodings.py $echo> foo.csv 

Bug#984703: libreoffice-calc: LibreOffice Calc executes code from current dir (encodings.py) when opening a .csv

[Rene Engelhard]

tag 984703 + moreinfo

tag 984703 + unreproducible

thanks


Hi,

Am 07.03.21 um 13:34 schrieb Milko Krachounov:
> When opening any CSV file with LibreOffice Calc, Calc opens and executes
> encodings.py from the current working directory.

Demonstrably wrong, see below.

>  That presumably happens because 
>
> Some file managers, including Krusader and mc, would launch localc in the 
> current directory, as would running it from the command line (such as
> `localc file.csv'), thereby running encodings.py from the directory
> containing the file.
>
> The issue is not present when LibreOffice is launched through the 
> application launcher, and the file is opened later through whatever 
> means (neither Open file, nor through a file manager or the command 
> line, since localc already operates in one's $HOME in that instance)
> To reproduce the issue, one needs to:
> 1. Close LibreOffice *completely*
> 2. In an empty directory, create "encodings.py" which raises an exception
Created a encodings.py which contains "foo", which surely is not valid
python.
> 3. In the same directory (for simplicity), create "file.csv" with some 
>rows.

Did.

1,2

ö,ä


(last line to be sure there is some encoding in there)


> 4. Open "file.csv" with `localc ./file.csv' using the directory containing
>"encodings.py" (double clicking in krusader and mc leads to the same
>result)

Done that.


> The result is that LibreOffice crashes with the Python exception raised
> by the rogue encodings.py, and then exits with an error that reads:
> Fatal Python error: initfsencoding: Unable to get the locale encoding

Just works here. Opens the .csv as is.


> The problem is present in both Debian Stable (1:6.1.5-3+deb10u6), and
> Buster Backports (1:7.0.4~rc2-1~bpo10+2).

Tried with 7.0.4-3 on bullseye (which should be identical to the
backport you use in this regard)


> No extensions not installed
> by apt are present on either machine (on the one with 6.1.5 I never
> installed any, and on the 7.0.4 I'm trusting what the LO extension 
> manager is telling me, since I cannot recall for sure)

Something else you did?

> Here's the console chatter:
>
> # Test on the host with 1:7.0.4~rc2-1~bpo10+2 - hostname is censored
> milko@host2 ~/Временна/LOSecurity $ cat > encodings.py

Maybe it is because of the *dir* this is in? I am so sure not creating a
cyrillic directory to check.

But even in a ~/öäü I just created, no crash and just an open of the .csv


> raise NotImplementedError("Darth Vader, Obi-Wan and Ahsoka walk into a bar")
> milko@host2 ~/Временна/LOSecurity $ cat > test.csv
> Column 1;Column 2;Column 3
> текст;ຂໍ້ຄວາມ;text
> milko@host2 ~/Временна/LOSecurity $ localc test.csv
> Fatal Python error: initfsencoding: Unable to get the locale encoding
> Traceback (most recent call last):
>   File "/home/milko/Временна/LOSecurity/encodings.py", line 1, in 
> NotImplementedError: Darth Vader, Obi-Wan and Ahsoka walk into a bar
> Fatal Python error: initfsencoding: Unable to get the locale encoding
> Traceback (most recent call last):
>   File "/home/milko/Временна/LOSecurity/encodings.py", line 1, in 
> NotImplementedError: Darth Vader, Obi-Wan and Ahsoka walk into a bar
> milko@host2 ~/Временна/LOSecurity $ cat > test2.csv
> Column 1;Column 2;Column 3
> text1;text2;text3
> milko@host2 ~/Временна/LOSecurity $ localc test2.csv
> Fatal Python error: initfsencoding: Unable to get the locale encoding
> Traceback (most recent call last):
>   File "/home/milko/Временна/LOSecurity/encodings.py", line 1, in 
> NotImplementedError: Darth Vader, Obi-Wan and Ahsoka walk into a bar
> Application Error
> milko@host2 ~/Временна/LOSecurity $

Even this doesn't produce any error. (in my ~/aöü)



>> Can yu pleas make this directly a public report in the Debian BTS?

Are you serious? For something unreproducible? Or were you able to
reproduce it?


Regards,


Rene

Bug#984703: libreoffice-calc: LibreOffice Calc executes code from current dir (encodings.py) when opening a .csv

[Rene Engelhard]

Hi again,

Am 07.03.21 um 13:34 schrieb Milko Krachounov:
> When opening any CSV file with LibreOffice Calc, Calc opens and executes
> encodings.py from the current working directory. That presumably happens
> because

There also is no  mention of any "encodings.py" in anything in
LibreOffice itself:

rene@frodo:~/LibreOffice/git/libreoffice-7-0-4$ git grep encodings
config_host/config_locales.h.in: * support all the locales and character
encodings that it has code
configure.ac:  tables for encodings mainly
targeted for a
cui/source/tabpages/tpline.cxx:// Convert URL encodings to
UI characters (e.g. %20 for spaces)

[ internal python3 (which we don't use) encoding stuff stripped ]

filter/qa/complex/filter/detection/typeDetection/TypeDetection.java:
 * is used as source for several encodings.
filter/source/graphicfilter/idxf/dxfreprd.cxx:// Its
Windows variant, and later releases used ANSI encodings for
filter/source/graphicfilter/idxf/dxfreprd.cxx://
encodings for storing to corresponding formats, but there's
filter/source/graphicfilter/idxf/dxfreprd.cxx://
$DWGCODEPAGE to encodings mappings
filter/source/msfilter/util.cxx:// in last-ditch broken-file-format
cases to guess the right 8bit encodings
framework/qa/complex/loadAllDocuments/CheckXComponentLoader.java: *
is used as source for several encodings.
include/filter/msfilter/util.hxx:/// i.e. useful when dealing with
legacy formats which use legacy text encodings without recording
include/rtl/string.h:for double-byte encodings, UTF-7, UTF-8).
include/rtl/tencinfo.h:Can be rather meaningless for encodings
that encode global state along
include/rtl/tencinfo.h:with the characters (e.g., ISO-2022
encodings).
include/rtl/tencinfo.h:Can be rather meaningless for encodings
that encode global state along
include/rtl/tencinfo.h:with the characters (e.g., ISO-2022
encodings).
include/rtl/tencinfo.h:characters (SS2 and SS3) used by some of
the EUC encodings (to denote
include/rtl/tencinfo.h:repertoire) do not imply that encodings
making use of these characters
include/rtl/tencinfo.h:have the CONTEXT property.  Examples of
encodings that do have the
include/rtl/tencinfo.h:CONTEXT property are the ISO-2022
encodings and UTF-7.
include/rtl/tencinfo.h:special purposes in some encodings.
include/rtl/textenc.h:/** The various supported text encodings.
include/rtl/textenc.h:Possible values include a wide range of
single- and multi-byte encodings
include/rtl/textenc.h:the ISO 10646 (Unicode) specific encodings
RTL_TEXTENCODING_UCS4 and
include/rtl/textenc.h:These encodings are not used for text encodings,
only used for
include/rtl/textenc.h:font-/textoutput encodings.
include/rtl/uri.h:converted to eCharset because it contains
(encodings of) unmappable
include/rtl/ustring.h:for double-byte encodings, UTF-7, UTF-8).
include/rtl/ustring.hxx:encodings, UTF-7, UTF-8).
include/rtl/ustring.hxx:encodings, UTF-7, UTF-8).
include/svx/txencbox.hxx:/** Fill with all known encodings but
exclude those matching one or more
include/svx/txencbox.hxx:  If nButIncludeInfoFlags is given,
encodings are included even if they
include/svx/txencbox.hxx:If , some specific encodings
are not listed, as they are a
include/svx/txencbox.hxx:/** Fill with all encodings known to the
dbtools::OCharsetMap but exclude
include/svx/txencbox.hxx:  If nButIncludeInfoFlags is given,
encodings are included even if they
include/svx/txencbox.hxx:If , some specific encodings
are not listed, as they are a
include/svx/txencbox.hxx:/** Fill with all known MIME encodings and
select the best according to
include/svx/txencbox.hxx:/** Fill with all known encodings but
exclude those matching one or more
include/svx/txencbox.hxx:If , some specific encodings
are not listed, as they are a
include/svx/txencbox.hxx:/** Fill with all encodings known to the
dbtools::OCharsetMap but exclude
include/svx/txencbox.hxx:If , some specific encodings
are not listed, as they are a
include/tools/tenccvt.hxx:/// encoding. The encodings could be different.
sal/osl/unx/nlsupport.cxx: * _nl_language_list[] is an array list of
supported encodings. Because
sal/osl/unx/nlsupport.cxx: * We are comparing the encodings case
insensitive, so the list has
sal/qa/rtl/uri/rtl_testuri.cxx:// Check encode with unusual text
encodings:
sal/rtl/ustring.cxx:   code here. Could be the case for
apple encodings */
sal/textenc/tcvtbyte.hxx:/** For those encodings only with unicode range
of 0x80 to 0xFF. */
sal/textenc/tcvtmb.cxx:/* then share many tables for different charset
encodings. */
sal/textenc/tcvtmb.cxx:/* so that extensions
that don't consider encodings */
sal/textenc/tcvtmb.cxx:/* so that extensions that don't
consider 

Bug#982859: libcmis-dev: allowable-actions.hxx uses non-existing file boost/shared_ptr.hpp

[Rene Engelhard]

Hi,

Am 15.02.21 um 15:56 schrieb Vincent Lefevre:
> Now, I don't know whether this file is really needed, in which case
> I suppose that there is a missing dependency on libboost1.74-dev
> (currently).

Hmm, yes.

Looks like libcmis-dev needs a Depends: libboost-dev...


Regards,


Rene

Bug#982562: general: Storing upstream signatures next to upstream tarballs is problematic

[Rene Engelhard]

Hi,

Am 11.02.21 um 21:59 schrieb Raphaël Hertzog:

> [1] For details it happened in dbus-glib:
> https://snapshot.debian.org/package/dbus-glib/0.110-2/ -> it has .asc file
> https://snapshot.debian.org/package/dbus-glib/0.110-3/ -> no .asc
> https://snapshot.debian.org/package/dbus-glib/0.110-4/ -> no .asc
> https://snapshot.debian.org/package/dbus-glib/0.110-5/ -> it has a
> different .asc file
>
Why should anything else than -1 have a .asc file anyways in the upload?

That's .orig.tar.xz (or whatever compression) and the accompanying
.orig.tar.xz.asc.

Since -2 etc don't upload the .orig again there's no need to upload the
signature of the .orig again.


(And then there ia slso the problem that subcomponent tarballs can't get
their .ascs when they need to be repa ckaged to fill dpkgs needs. So
stuff like LO only gets the .asc for the "core" tarball but not for
helpcontent2 and translations, which would have .asc files otherwise)

Regards,


Rene

Bug#982274: usr.lib.libreoffice.program.soffice.bin: temporary files are not allowed due to length change

[Rene Engelhard]

Hi,

Am 08.02.21 um 03:15 schrieb Paul Wise:

> Tags: patch

No, No patch.

patch does not  mean "add a ?" but if at all someting like this

$ git diff sysui/desktop/apparmor/program.soffice.bin
diff --git a/sysui/desktop/apparmor/program.soffice.bin
b/sysui/desktop/apparmor/program.soffice.bin
index 42053db2abef..83bd9d11f93c 100644
--- a/sysui/desktop/apparmor/program.soffice.bin
+++ b/sysui/desktop/apparmor/program.soffice.bin
@@ -101,7 +101,7 @@ profile libreoffice-soffice
INSTDIR-program/soffice.bin {
   owner @{libo_user_dirs}/**/   rw,  #allow creating
directories that we own
   owner @{libo_user_dirs}/**~lock.* rw,  #lock file support
   owner @{libo_user_dirs}/**.@{libreoffice_ext} rwk,  #Open files rw
with the right exts
-  owner @{libo_user_dirs}/{,**/}lu??{,?}.tmp rwk, #Temporary
file used when saving
+  owner @{libo_user_dirs}/{,**/}lu???{,?}.tmp rwk, #Temporary
file used when saving
   owner @{libo_user_dirs}/{,**/}.directory r, #Read directory settings
on KDE
 
   # Settings
(Which is even trivially to do in /etc/apparmor.d if you don't know the
source path. This won
t necessarily help since the path is there in the generated file but if
yoz're lucky and are far away "enough" from the profile path..)


Not removing the patch since it's now actually has one..

> When I open a document in my home directory in libreoffice I get this:
>
>Feb 08 08:08:48 audit[474619]: AVC apparmor="DENIED" operation="open" 
> profile="libreoffice-soffice" name="/home/pabs/lu474619vthyvt.tmp" pid=474619 
> comm="soffice.bin" requested_mask="wrc" denied_mask="wrc" fsuid=1000 ouid=1000

Didn't you already ask on IRC some weeks ago about this?


Did you manually set it to enabled from the default complain-only mode
or how did the soffice.bin get into complain mode?

> The reason is that this rule allowing temporary files is too short:
>
>  owner @{libo_user_dirs}/{,**/}lu??{,?}.tmp rwk, #Temporary file 
> used when saving
>
> Adding one more possible temporary filename length fixes the denial:
>
>  owner @{libo_user_dirs}/{,**/}lu??{,?,??}.tmp rwk, #Temporary 
> file used when saving

Did you change it or do you mean upstream did?

Addendum: Yes, apprarently something changed and it got hidden due to it
being complain-only.

Indeed I get ALLOWED entries in the log.


Regards,


Rene

Bug#979439: hunspell-it: Italian spell check cannot recognize simple words

[Rene Engelhard]

Hi again,

Am 13.01.21 um 20:59 schrieb Rene Engelhard:
> Am 13.01.21 um 19:43 schrieb Antonio:
>> I solved it by changing this line of the file
>> "/usr/share/hunspell/it_IT.aff":
>>
>> --- it_IT.aff.orig.bad  2021-01-13 19:28:38.184457124 +0100
>> +++ it_IT.aff.new.ok   2021-01-13 19:38:06.141194317 +0100
>> @@ -36,7 +36,7 @@
>>  LANG it_IT
>>  HOME https://libreitalia.org
>>  VERSION 5.1.0 (13/10/2020)
>> -SET UTF-8
>> +SET ISO8859-15
>>  TRY
>> aioertnsclmdpgubzfvhàq'ACMSkBGPLxEyRTVòIODNwFéùÚìjUZKHWJYQXÃÃ
>>  # Nota: non presenti nel dizionario: ÃÃ, vanno aggiunte alla TRY
>> rigenerata
>>
> Interesting.
>
> rene@frodo:~/LibreOffice/git/master/dictionaries/it_IT$ file it_IT.aff
> it_IT.aff: UTF-8 Unicode text
> rene@frodo:~/LibreOffice/git/master/dictionaries/it_IT$ file it_IT.dic
> it_IT.dic: ISO-8859 text
> $
>
>
> Someone wasn't able to decide ;-). I'd argue that UTF-8 is the future
> and that would possible mean a simply recode of it_IT.dic to UTF-8
> should also fix it?

In a quick try here with the UDHR in Italian as suggested by the
reporter a simple

$ sudo recode ISO8859-15...UTF-8 /usr/share/hunspell/it_IT.dic

makes it work indeed.


Regards,


Rene

Bug#979439: hunspell-it: Italian spell check cannot recognize simple words

[Rene Engelhard]

Hi Antonio,

Am 13.01.21 um 19:43 schrieb Antonio:
> I solved it by changing this line of the file
> "/usr/share/hunspell/it_IT.aff":
>
> --- it_IT.aff.orig.bad  2021-01-13 19:28:38.184457124 +0100
> +++ it_IT.aff.new.ok   2021-01-13 19:38:06.141194317 +0100
> @@ -36,7 +36,7 @@
>  LANG it_IT
>  HOME https://libreitalia.org
>  VERSION 5.1.0 (13/10/2020)
> -SET UTF-8
> +SET ISO8859-15
>  TRY
> aioertnsclmdpgubzfvhàq'ACMSkBGPLxEyRTVòIODNwFéùÚìjUZKHWJYQXÃÃ
>  # Nota: non presenti nel dizionario: ÃÃ, vanno aggiunte alla TRY
> rigenerata
>
Interesting.

rene@frodo:~/LibreOffice/git/master/dictionaries/it_IT$ file it_IT.aff
it_IT.aff: UTF-8 Unicode text
rene@frodo:~/LibreOffice/git/master/dictionaries/it_IT$ file it_IT.dic
it_IT.dic: ISO-8859 text
$


Someone wasn't able to decide ;-). I'd argue that UTF-8 is the future
and that would possible mean a simply recode of it_IT.dic to UTF-8
should also fix it?

I probably would prefer that over patching the .aff to use the old
ISO8859-15.

Regards,


Rene

Bug#979439: hunspell-it: Italian spell check cannot recognize simple words

[Rene Engelhard]

Hi,

Am 13.01.21 um 10:36 schrieb g.l. gragnani:
> Package: hunspell-it
> Version: 1:7.1.0~rc1-1
> Followup-For: Bug #979439
>
> Dear Maintainer,
>
> I can confirm this bug for both LibreOffice and Thunderbird  (1:78.6.0-1)
> According to the program isutf8 (package moreutils)
> the file /usr/share/hunspell/it_IT.dic IS NOT utf-8 encoded.
> Could it be the problem?

Could theoretically be, yes.

But then I wonder why it's claimed to work with a stock LO, which
doesn't specify any encoding either to that file.


And it_IT.dic is not the only one:


rene@frodo:~/LibreOffice/git/master/dictionaries$ find . -name "*.dic"
-exec file {} \; | grep -v UTF
./en/en_AU.dic: ASCII text
./en/en_US.dic: ASCII text
./en/en_CA.dic: ASCII text
./sw_TZ/sw_TZ.dic: ASCII text
./lt_LT/hyph_lt.dic: ISO-8859 text
./lt_LT/lt.dic: ISO-8859 text
./et_EE/et_EE.dic: ISO-8859 text
./et_EE/hyph_et_EE.dic: ISO-8859 text
./el_GR/hyph_el_GR.dic: ISO-8859 text
./el_GR/el_GR.dic: ISO-8859 text
./sr/hyph_sr.dic: ISO-8859 text
./sr/hyph_sr-Latn.dic: ISO-8859 text
./an_ES/an_ES.dic: data
./nl_NL/hyph_nl_NL.dic: troff or preprocessor input, ISO-8859 text
./lv_LV/hyph_lv_LV.dic: ISO-8859 text
./sk_SK/hyph_sk_SK.dic: ISO-8859 text
./pt_PT/hyph_pt_PT.dic: ISO-8859 text
./pl_PL/pl_PL.dic: ISO-8859 text
./pl_PL/hyph_pl_PL.dic: troff or preprocessor input, ISO-8859 text
./da_DK/hyph_da_DK.dic: ISO-8859 text
./gl/hyph_gl.dic: troff or preprocessor input, ASCII text
./id/hyph_id_ID.dic: ASCII text
./id/id_ID.dic: ASCII text
./de/hyph_de_DE.dic: ISO-8859 text
./de/hyph_de_AT.dic: ISO-8859 text
./de/de_AT_frami.dic: ISO-8859 text
./de/de_CH_frami.dic: ISO-8859 text
./de/hyph_de_CH.dic: ISO-8859 text
./de/de_DE_frami.dic: ISO-8859 text
./no/nb_NO.dic: ISO-8859 text
./no/nn_NO.dic: ISO-8859 text
./no/hyph_nb_NO.dic: troff or preprocessor input, ISO-8859 text
./no/hyph_nn_NO.dic: troff or preprocessor input, ISO-8859 text
./bs_BA/bs_BA.dic: ISO-8859 text
./hr_HR/hyph_hr_HR.dic: ISO-8859 text
./cs_CZ/cs_CZ.dic: ISO-8859 text
./cs_CZ/hyph_cs_CZ.dic: troff or preprocessor input, ISO-8859 text
./zu_ZA/hyph_zu_ZA.dic: ASCII text
./sl_SI/sl_SI.dic: ISO-8859 text
./sl_SI/hyph_sl_SI.dic: ISO-8859 text
./af_ZA/hyph_af_ZA.dic: ISO-8859 text
./it_IT/hyph_it_IT.dic: ASCII text
./it_IT/it_IT.dic: ISO-8859 text
./sv_SE/hyph_sv.dic: ISO-8859 text
$


Regards,


Rene

Bug#980013: libreoffice fails throwing com::sun::star::uno::RuntimeException

[Rene Engelhard]

tag 980013 + moreinfo

tag 980013 + unreproducible

thanks


Hi,

Am 12.01.21 um 22:54 schrieb Nick Bailey:
> access("/tmp", W_OK)= 0
> getuid()= 1000
> socket(AF_UNIX, SOCK_STREAM, 0) = 3
> fcntl(3, F_SETFD, FD_CLOEXEC)   = 0
> connect(3, {sa_family=AF_UNIX, 
> sun_path="/tmp/OSL_PIPE_1000_SingleOfficeIPC_e68685edcbca78b5debcd31a7a395fac"},
>  110) = -1 ECONNREFUSED (Connection refused)
> close(3)= 0
> stat("/proc/version", {st_mode=S_IFREG|0444, st_size=0, ...}) = 0
> stat("/usr/lib/libreoffice/program/", {st_mode=S_IFDIR|0755, st_size=20480, 
> ...}) = 0
> openat(AT_FDCWD, "/sys/dev/block/254:0/queue/rotational", O_RDONLY) = 3
> close(3)= 0
Which is normal tht
> The named OSL_PIPE is left in /tmp after the program fails.
>
> This behaviour has arisen after (but not immediately after) upgrading
> the installation from Buster to Bullseye. 
But?
> I cannot find any left-over packages
> from the old installation.

I can find brokeness in your installation.


Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE


Nvidia crap?


> Versions of packages libreoffice-core recommends:
> ii  gstreamer1.0-libav 1:1.14.4-dmo3
[...]
> ii  gstreamer1.0-plugins-ugly  1:1.14.4-dmo2

Sigh, dmo.



> Versions of packages libreoffice-writer depends on:
> ii  libabw-0.1-1 0.1.3-1
> ii  libc62.31-9
> ii  libe-book-0.1-1  0.1.3-2
> ii  libepubgen-0.1-1 0.1.1-1
> ii  libetonyek-0.1-1 0.1.9-4
> ii  libgcc-s110.2.1-3
> ii  libicu67 67.1-5
> ii  libmwaw-0.3-30.3.17-1
> ii  libodfgen-0.1-1  0.1.7-1
> ii  libreoffice-base-core1:7.0.4-3
> ii  libreoffice-common   1:7.0.4-3
> ii  libreoffice-core 1:7.0.4-3
> pn  librevenge-0.0-0 
[...]
> pn  libwpd-0.10-10   
> pn  libwpg-0.3-3 

How on earth did you get into a situation where a dependency is not
there? Did you force it's removal of what?


Anyways, just works for me, and for gazillions of other people since if
it was a real problem a report would have been there far earlier.


Regards,


Rene

Bug#978431: texlive-base: dist-upgrade buster->bullseye fails

[Rene Engelhard]

Package: texlive-base
Version: 2020.20201203-2
Severity: serious

Hi,

dist-upgrade buster->bullseye which just caused my system to not get out of apt 
-f install anymore:

Entpacken von texlive-base (2020.20201203-2) über (2018.20190227-2) ...
dpkg: Fehler beim Bearbeiten des Archivs 
/tmp/apt-dpkg-install-nSKKZq/20-texlive-base_2020.20201203-2_all.deb (--unpack):
 Versuch, »/usr/share/doc/texlive-doc/generic/iftex/iftex.pdf« zu 
überschreiben, welches auch in Paket texlive-plain-generic 2018.20190227-2 ist
dpkg-deb: Fehler: »einfügen«-Unterprozess wurde durch Signal (Datenübergabe 
unterbrochen (broken pipe)) getötet
Regenerating '/var/lib/texmf/fmtutil.cnf-DEBIAN'... done.
Regenerating '/var/lib/texmf/fmtutil.cnf-TEXLIVEDIST'... done.
update-fmtutil has updated the following file(s):
/var/lib/texmf/fmtutil.cnf-DEBIAN
/var/lib/texmf/fmtutil.cnf-TEXLIVEDIST
If you want to activate the changes in the above file(s),
you should run fmtutil-sys or fmtutil.
[...]

Regards,

Rene

Bug#977977: libreoffice: a large part of the window appears off-screen

[Rene Engelhard]

retitle 977977 libreoffice: a large part of the window might appear
off-screen if resultion/monitor config changes

Hi,

Am 23.12.20 um 20:34 schrieb Vincent Lefevre:
> On 2020-12-23 19:53:09 +0100, Rene Engelhard wrote:
>> Am 23.12.20 um 18:59 schrieb Vincent Lefevre:
>>> A large part of the window appears off-screen, including the menu
>>> and window controls. Basically, the only thing I can do is to type
>>> Ctrl-Q to quit Libreoffice!
>> And why is that? Obviously works on one-monitor setups.
> My machine is a laptop, sometimes with only its screen, sometimes
> with 2 external 4K monitors, depending on where I am.
Aha. I have none of these. (Besides that my laptop has a sane graphics
card.)
>> And given you apparently use the nvidia driver (see below) No way to
>> reproduce this here.
> The nouveau driver is unusable with an external monitor (even when
> used in mirror mode). The nvidia driver is the only solution with
> such a configuration.

In Germany we have an idiom amongst IT people: "Augen auf beim
Hardwarekauf" (which roughly translates to

"open your eyes when buying hardware"). You got into this situation
yourself.


> I did not set anything special. I rarely use LibreOffice (only when I
> need to). And I don't think I have ever changed anything explicitly in
> the preferences. In short, I let LibreOffice handle the config on its
> own.

OK, but I believe it saves it's dimensions when closed, I at laest get
this when williy-nilly dragging the window.

It probably also saves the location..


This would explain your problem. I don't think there is a senseful way
to fix this though. Always start maximized (and automatically on the
current monitor/display)? Probably not.

In any case, this is something for upstream - not Debian to change. And
for that there's reportbug mentioning that upstream bugs should go upstream.


> That's the default for unstable, except that I added experimental. 

No, it's not.

Adding stable and testing is not. (unstable-debug is understandable, but
also not default.)

> Currently everything has been installed
> from unstable
Sure.
>  (or testing or stable, when this was the latest package
> version).
But there's no need for stable or testing here.
>>> Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
>>> TAINT_UNSIGNED_MODULE
>> Try with a sane system?
> AFAIK, that's just due to the nvidia driver, for the reason explained
> above.

Which proves my point. (I do not care about nvidia.)


Regards,


Rene

Bug#977857: libreoffice-common: On Wayland, it doesn't work without the xwayland pkg but installation does not pull xwayland as a dependency

[Rene Engelhard]

Hi,

Am 22.12.20 um 01:07 schrieb jman:
> In order to make Libreoffice work, the package `xwayland` should be installed 
> as a dependency.
It doesn't scale to add a xwayland dependency on every package doing X
operations.

> Unless I'm wrong, I believe the real issue is that Libreoffice does not work 
> on a pure Wayland
> installation, but this fact is not very clear to the user.

Is this common? I mean this would haven been reported far earlier/in
many more cases? Isn't the "GNOME" Session defaulting to wayland nowadays?

rene@frodo:~$ grep-dctrl -FRecommends xwayland
/var/lib/apt/lists/deb.debian.org_debian_dists_sid_main_binary-amd64_Packages
-sPackage
Package: mir-demos
Package: mir-test-tools
rene@frodo:~$ grep-dctrl -FDepends xwayland
/var/lib/apt/lists/deb.debian.org_debian_dists_sid_main_binary-amd64_Packages
-sPackage
Package: gnome-session-bin
Package: kwin-wayland
rene@frodo:~$

Ah, both GNOME and KDE depend on xwayland. Which DE/WM do you use?

>  I've tried searching for related issue on
> the Libreoffice buttracker but found none.

There is https://bugs.documentfoundation.org/show_bug.cgi?id=121275 but
that one's closed and didn't (apparently) even get a console output.

And the fix was using gtk3, which you did...


(Wrt your other mail, that package list is so obviously incomplete - and
we TTBOMK don't patch any place which should affect this. What we do
differ in is using system-libraries where possible - so one of these
might affect this?=

Regards,


Rene

Bug#977977: libreoffice: a large part of the window appears off-screen

[Rene Engelhard]

tag 977977 + unreproducible

tag 977977 + moreinfo

thanks

Hi,


Am 23.12.20 um 18:59 schrieb Vincent Lefevre:

> Severity: important

Sigh.

> A large part of the window appears off-screen, including the menu
> and window controls. Basically, the only thing I can do is to type
> Ctrl-Q to quit Libreoffice!

And why is that? Obviously works on one-monitor setups.

And given you apparently use the nvidia driver (see below) No way to
reproduce this here.

> As a workaround, I had to remove my configs (~/.config/libreoffice).

And then it works? What did you set specifically in  that profile which
might got reset and made it working? Did you change something inbetween
which might make LO remember where it was and saved it somehow?

> Debian Release: bullseye/sid
>   APT prefers unstable-debug
>   APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 
> 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental')

I never will understand the sense in this configuration. Anything you
will get is from unstable anyway.


> Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
> TAINT_UNSIGNED_MODULE

Try with a sane system?

Regards,


Rene

Bug#950319: libreoffice: filename replacements in mime entries for mailcap must not be quoted within the given command

[Rene Engelhard]

Hi,

Am 17.12.20 um 00:48 schrieb Marriott NZ:
> Unfortunately no progress yet on #928037, but I wanted to add here some info 
> from related bug reports.
>
> 1) There is a Lintian test for this specific problem:
> https://lintian.debian.org/tags/quoted-placeholder-in-mailcap-entry.html
> Package libreoffice and 40 more, currently trigger the warning.
> The test was introduced in Lintian 2.42.0, 19 Dec 2019.
> The bug report requesting the test dates back to 17 Feb 1999:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=33486

I know and saw that one, and as long as there isn't a *definitive*
answer am continuing what I am doing already: ignoring it.

Or is lintians tag is a distro-wide decision? I don't take that for a
given since they introduce bogus tags all the time .oO ( "breakout-link" )

> 2) The problem has already been discussed in old bugs, usually reaching the 
> conclusion that %-escapes should *not* be quoted in the rules:
*usually*?
> Unfortunately they decided not to document anything because "I would like to 
> avoid divergence with other platforms":
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=90483#30

Fair point, IMHO.


> As a result, many years later, every piece of Debian concerning mailcap is 
> still a vector for arbitrary command execution, while package maintainers 
> have no way of knowing what to do, and bug reports keep resurrecting like 
> zombies (my #928037 is a duplicate of 10yo #90483).

As we see here, too.


> 3) Thunderbird doesn't use the %-expansion in the rules at all.
> The parsing function extracts what it thinks is the "executable name" and 
> returns just that.
>
> https://hg.mozilla.org/mozilla-central/file/661f0d8ae4c44db58e668c831b555dbc038b77d0/uriloader/exthandler/unix/nsOSHelperAppService.cpp
>
> From function UnescapeCommand:
>   "UnescapeCommand really needs some work -- it should actually do some 
> unescaping"
> From function GetHandlerAndDescriptionFromMailcapFile:
>   // XXX ugly hack.  Just grab the executable name
>   ...
>   // XXX End ugly hack
>
> I don't know about Evolution.
>
That would be important info - and please don't forget mutt et al.


Regards,


Rene

Bug#976463: Libreoffice translation

[Rene Engelhard]

Hi,

for avoidance of doubt:

Am 05.12.20 um 13:47 schrieb Rene Engelhard:
> Though Debian does not ship anything which contains this script. We

file in a package that is. Of course I could patch this but this would
be a no-op in Debian.

> same dicts are also used by other applications), here:

Here I wanted to include what I cut'n'pasted in my first reply already
but hit send too fast..

> If you want it fixed upstream for their extensions, please file it upstream.

Especially as if I forwarded it upstream you probably needed to submit a
license statement anyways.

Regards,

Rene

Bug#975951: libreoffice tries to access files of firefox profiles (AppArmor)

[Rene Engelhard]

Hi,

On Fri, Nov 27, 2020 at 07:25:19PM +0100, Jörg Sommer wrote:
> Rene Engelhard schrieb am Fr 27. Nov, 16:48 (+0100):
> > > Package: libreoffice
> >
> > No, libreoffice does not contain anything except dependencies. Do you mean 
> > libreoffice-core?
>
> I don't know which package contains this functionality. And it shouldn't
> matter. I file a bug report to a *project* and I'm really don't know which

No, you file it against a *package*. If there was no libreoffice dummy package
reporing it against libreoffice would simply result in a bug for 
"unknown-package",
there is no "filing against a project" in Debians BTS. :)

> You might view a bug report as an incident in a component

That's what "bug" implies, yes... And you filed it as a "normal" bug :)

> and would like to organize all bug reports.

Exactly.

> > How it is a bug when LO does what it's supposed to do in case people want to
> > sign their documents (with S/MIME, gpg is something else) *and which is
> > documented*?
>
> I didn't touch anything that had to do with signing. I've got a document
> as a mail attachment and hit enter. I use LibreOffice four or five times
> per year.

Me too :)

Anyways, that probably means it initializes xmlsecurity/nss and thus acesses 
this.

> To be fair I don't look at my logs.

You wrote in your initial report "I'm seeing many entries like these in my 
log:".

> But I get AppArmor messages via mail. That's why I've spotted this (and
> other) problems.
>
> > > operation="open" profile="libreoffice-soffice" 
> > > name="/home/joerg/.mozilla/firefox/aelzkv52.dev/cert9.db" pid=486621 
> > > comm="soffice.bin" requested_mask="wc" denied_mask="wc" fsuid=1000 
> > > ouid=1000
> > > operation="file_lock" profile="libreoffice-soffice" 
> > > name="/home/joerg/.mozilla/firefox/aelzkv52.dev/cert9.db" pid=486621 
> > > comm="soffice.bin" requested_mask="k" denied_mask="k" fsuid=1000 ouid=1000
> >
> > Access to the Mozilla profile is completely expected in how it's
>
> Yes, that's what you expect, but a) the AppArmor rules expect something
> else

They (apparently) miss key4.db, yes. Otherwise they allow "r" access.

"w" or "c" access shoudn't be allowed and yes, upstream acknowldeges it should 
probably
just be open "r"ead-only. (which is included in the IRC logs I sent in my other 
reply)

If you read what I wrote in my initial reply: I didn't deny that the profie 
might need
adaptions.

That doesn't change that you say in this bug that this access shouldn't happen 
at all,
which somewhat can agree with but as long as they use nss and don't want 
~/.pki/nssdb
because there is no (GUI) key management tool for this this discussion is moot.

It's not Debians "job" to replace something integral like this which also 
probably affects
file format and standards by something else.

> and b) from a generic point of view, I as a software developer
> wouldn't expect any project accessing the internal files of another
> project. This makes any change very difficult, because you have to
> consider all possible external users if you touch anything. That's
> horrible.

Internal details are handled by the nss security library.

Which knows the format because it's it's native format.
(That's why the mozilla profile is used in the first place anyway, LO
just initializes possible locations.)

> > Key *management* is something LO should not do and cannot do anyway. (same 
> > with gpg)
>
> Yes, indeed. Why doesn't it use helper tools like openssl?

See my other reply. They care more about end-users with no clue
instead of "openssl" or "certutil" for that matter...

> It requests the tools for it.

... and LO doesn't do any key management either. It just initializes the XML
signing library, which uses nss. (and not openssl, which is IMHO bad,
I agree.)

> At least, I can tell (but this is another problem) LibreOffice crashes
> with gpg using tofu.
>
> apparmor="DENIED" operation="open" profile="libreoffice-soffice//gpg" 
> name="/home/joerg/.gnupg/tofu.db" pid=708430 comm="gpg" requested_mask="wc" 
> denied_mask="wc" fsuid=1000 ouid=1000
>
> If you don't care about it drop this. I've fixed it for me, so it doesn't
> bother me any more.

Again that "tofu" gpg thingy...

Is there any website or so recommending to set this?

This is not default and "normal" gpg just works. See also
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=955271 where this already
was reported.

If you chan

Bug#975951: libreoffice tries to access files of firefox profiles (AppArmor)

[Rene Engelhard]

Hi,

On Fri, Nov 27, 2020 at 04:48:22PM +0100, Rene Engelhard wrote:
> 16:41 < _rene_> is there any plan to be able to use /.pki/nssdb? (see
> https://wiki.mozilla.org/NSS_Shared_DB_And_LINUX)
> 16:41 < _rene_> instead of the mozilla profile?
> 16:42 -!- hallnknight
> [~hallnknig@2401:4900:3b30:951d:983d:6f8:9c88:2aef] has joined
> #libreoffice-dev
> 16:42 < _rene_> (context:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=975951 and
> https://bugs.documentfoundation.org/show_bug.cgi?id=119811)
> 16:42 < IZBot> bug 119811: LibreOffice-LibreOffice normal/medium NEW
> LibreOffice 6.0.6 spies on my Firefox keychain when opening MS documents
> 16:43 < mst___> _rene_, if there's some UI for users to add their certs
> to that location then sure
> 16:44 < _rene_> one can do so without a UI? not everything needs a UI?
> 16:44 < _rene_> at least make it honour that path in addition
> 16:45 < _rene_> mst___: users nowadays also don't use firefox :)
16:48 <@thorsten> _rene_: thought nss can only use one path?
16:49 < _rene_> no idea, can't one initialize nss two times and use one 
instance for firefox and the other for that one?
16:49 < _rene_> I mean, there must be more application not relying only on 
firefox?
16:50 <@thorsten> we had similar issues with thunderbird vs. firefox cert 
stores,
16:50 < _rene_> mmh
16:50 <@thorsten> IIRC the suggestion was for users to set the proper env var,
16:50 <@thorsten> and we're off the hook?
16:50 <@vmiklos> or just set their preferred path in LO, using tools -> options
16:51 < _rene_> but MOZILLA_CERTIFICATE_FOLDER if you mean that will expect a 
firefox profile and not work with ~/.pki/nssdb, will it?
16:52 <@vmiklos> you would have to check, possibly both just contain files like 
certX.db and keyY.db, so perhaps works out of the box
16:52 -!- OlegShtch [~Thunderbi@37.112.63.140] has joined #libreoffice-dev
16:52 < _rene_> ah, right, there's the "Options", didn't know
16:54 < _rene_> ok, related to this:
16:54 < _rene_> why does LO request w permissions?
16:54 < _rene_> r should simply suffice, shouldn't it?
16:55 < _rene_> or is this nss actually opening it? (I guess so...)
16:56 -!- hallnknight [~hallnknig@2401:4900:3b30:951d:983d:6f8:9c88:2aef] has 
quit [Ping timeout: 264 seconds]
16:56 -!- sberg [~sb...@dynamic-077-003-206-224.77.3.pool.telefonica.de] has 
quit [Quit: Leaving]
16:56 <@vmiklos> i guess ideally it should be read-only, right.
16:56 -!- hallnknight [~hallnknig@223.187.154.213] has joined #libreoffice-dev
16:57  * _rene_ writes that into 
https://bugs.documentfoundation.org/show_bug.cgi?id=119811
16:57 < IZBot> bug 119811: LibreOffice-LibreOffice normal/medium NEW 
LibreOffice 6.0.6 spies on my Firefox keychain when opening MS documents
16:57 < _rene_> (with the chat here cut'n'pasted)

So one can set ~/.pki/nssdb oneself (but then the apparmor profile should 
probably be adapted), but
the default will not change in LO (see above).

Regards,
 
Rene

Bug#975951: libreoffice tries to access files of firefox profiles (AppArmor)

[Rene Engelhard]

Hi,

On Fri, Nov 27, 2020 at 02:31:08PM +0100, Jörg Sommer wrote:
> How about using ~/.pki/nssdb? https://wiki.mozilla.org/NSS_Shared_DB_And_LINUX

Oh, didn't know about that one.

The reaction was predictable, though:

16:41 < _rene_> is there any plan to be able to use /.pki/nssdb? (see
https://wiki.mozilla.org/NSS_Shared_DB_And_LINUX)
16:41 < _rene_> instead of the mozilla profile?
16:42 -!- hallnknight
[~hallnknig@2401:4900:3b30:951d:983d:6f8:9c88:2aef] has joined
#libreoffice-dev
16:42 < _rene_> (context:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=975951 and
https://bugs.documentfoundation.org/show_bug.cgi?id=119811)
16:42 < IZBot> bug 119811: LibreOffice-LibreOffice normal/medium NEW
LibreOffice 6.0.6 spies on my Firefox keychain when opening MS documents
16:43 < mst___> _rene_, if there's some UI for users to add their certs
to that location then sure
16:44 < _rene_> one can do so without a UI? not everything needs a UI?
16:44 < _rene_> at least make it honour that path in addition
16:45 < _rene_> mst___: users nowadays also don't use firefox :)

Regards,

Rene

Bug#975951: libreoffice tries to access files of firefox profiles (AppArmor)

[Rene Engelhard]

severity 975951 minor
tag 975951 upstream
forwarded 975951 https://bugs.documentfoundation.org/show_bug.cgi?id=119811
retitle 975951 libreoffice tries to access files of firefox profiles
notfound 975951 1:7.0.3-4+b1
thanks

Hi,

> Package: libreoffice

No, libreoffice does not contain anything except dependencies. Do you mean 
libreoffice-core?

Sorry, that it hits you, but why can't people just file against the correct 
package? "libreoffice"
clearly says it's a dummy package.

> Severity: normal

Sigh.

How it is a bug when LO does what it's supposed to do in case people want to
sign their documents (with S/MIME, gpg is something else) *and which is 
documented*?

https://help.libreoffice.org/4.4/Common/Applying_Digital_Signatures
(of course also valid for later versions, this is just a result of googling.)


https://wiki.openoffice.org/wiki/How_to_use_digital_Signatures


That's what it is for. Signing documents with S/MIME.

> I'm seeing many entries like these in my log:

If you look at your logs (which is good) I would also expect you being able to 
do a basic resarch
(see above) instead of filing a "bug" which then will linger around until 
eternity :-(

> operation="open" profile="libreoffice-soffice" 
> name="/home/joerg/.mozilla/firefox/aelzkv52.dev/cert9.db" pid=486621 
> comm="soffice.bin" requested_mask="wc" denied_mask="wc" fsuid=1000 ouid=1000
> operation="file_lock" profile="libreoffice-soffice" 
> name="/home/joerg/.mozilla/firefox/aelzkv52.dev/cert9.db" pid=486621 
> comm="soffice.bin" requested_mask="k" denied_mask="k" fsuid=1000 ouid=1000

Access to the Mozilla profile is completely expected in how it's

(The apparmor profiles allow "r", not "w". (Have to lookup what "c" is.) which 
is correct since

LO should only be able to read the certs).

 
Key *management* is something LO should not do and cannot do anyway. (same with 
gpg)

> operation="open" profile="libreoffice-soffice" 
> name="/home/joerg/.mozilla/firefox/aelzkv52.dev/key4.db" pid=486621 
> comm="soffice.bin" requested_mask="wrc" denied_mask="wrc" fsuid=1000 ouid=1000
> operation="file_lock" profile="libreoffice-soffice" 
> name="/home/joerg/.mozilla/firefox/aelzkv52.dev/key4.db" pid=486621 
> comm="soffice.bin" requested_mask="k" denied_mask="k" fsuid=1000 ouid=1000

Oh, that one's new.

I added the cert?.db ones once.

Since when does LO (and/or nss and or libxmlsec-nss) want key4.db, too?
(But I'd only allow r anyways.)

 
I guess I need to check whether signing works when the profile is in
enforcing again...

> LibreOffice tries to access the key storage of Firefox, which is really
> strange.

No, it isn't.

A few minutes' research would have shown you that it uses nss and the
certificates from Firefox (or Thundebird or SeaMonkey..):

https://www.google.com/search?q=libreoffice+firefox+profile=1C1GCEU_deDE843DE846=libreoffi=chrome.1.69i60j69i59j69i57j69i60l3j69i65j69i60.2319j0j7=chrome=UTF-8

Second and fourth hit.

(That also shows https://bugs.documentfoundation.org/show_bug.cgi?id=119811
where an other user just reports a "bug" because of something unexepctedly 
("no visiable reasons"...)

Yes, it's 
Marking as forwarded to this "bug" though.

> Isn't it possible to use the keys in /etc/ssl?

a) as said it uses nss instead of the "standard" openssl, and has to use
   what nss expects
b) how are you going to add signing certificates as user to /etc/ssl without
   being root?

How does a end-user know (s)he needs to add stuff there? There (ttbomk) 
unfortunately also is no standardized patch for certs in users' $HOMEs.

And (unfortunately) LO wants to cater for end-users with no clue instead of
doing the correct thing(tm).

Regards,

Rene

Bug#975928: libreoffice: Please reimport the scale option in the view settings

[Rene Engelhard]

tag 975928 + upstream

forwarded 975928
https://bugs.documentfoundation.org/show_bug.cgi?id=101646


thanks


Hi,

Am 26.11.20 um 20:18 schrieb Hans-J. Ullrich:
> as there are now screens with high resolutions, the font of the menus are 
> very tiny now. Especially for older people Libreoffice is hardly to use, due 
> to the tiny font in the menu bar on top.
You can't use accessibility tools of yor desktop? Either increase the
font size globally or use "magnifier" or so?
> In former versions of Libreoffice there was a scale setting option in Extras 
> -> Options -> Libreoffice -> View, but today this usefull feature is gone.
>
> It would be nice and very, very helpfull, if you could set this back again.

Me? Not.

Upstream? Yes, maybe.


Doesn't look like it will happen soonish, though, see

https://bugs.documentfoundation.org/show_bug.cgi?id=101646



Regards,


Rene

Bug#975481: Use libmariadb-dev instead of legacy libmariadbclient-dev

[Rene Engelhard]

severity 975481 wishlist

tag 975481 + moreinfo

thanks

Am 22.11.20 um 19:15 schrieb Otto Kekäläinen:
> Package: libreoffice

How is this a normal bug? Please a bit more care when reporting bugs.

Either it's a wish or libmariadbclient-dev is supposed to be removed
soonish at which it would be at least important.

> I noticed the source package has references to libmariadbclient-dev:
> https://salsa.debian.org/search?search=libmariadbclient-dev_id=1012_id=2250

changelog is of a total obsolete version. Note the "bump
build-dependency on icu to >= 52 (see" and opencollada which isn't a
thing anymore even in buster.

The first rules part

ifneq (,$(filter mariadb, $(SYSTEM_STUFF)))
# deducted from default-libmysqlclient-dev Depends
BUILD_DEPS += , libmariadbclient-dev-compat
endif
MARIADBCONFIG=/usr/bin/mariadb_config

is not used as it's inside an ifeq "$(MYSQL_FLAVOUR)" "mariadb"
and MYSQL_FLAVOUR is set to default in rules (aka use 
default-libmysqlclient-dev).

The second rules part

ifeq "$(MYSQL_FLAVOUR)" "mysql"
perl -pi -e "s/(Build-Conflicts: .*)/\1,libmariadbclient-dev,/"
debian/control
endif
ifneq (nocheck,$(findstring nocheck,$(DEB_BUILD_OPTIONS)))

is (as you see in the snippet) only used with MYSQL_FLAVOUR=mysql (which won't 
ever be set, will only bet set ever if it's "real" MySQL to be used)

Don't just grep for stuff but check what packages actually do.

> This is a deprecated package and you should instead use
> libmariadb-dev[1] or libmariadb-dev-compat if you need to build
> something old that does not find the correct soname otherwise.

Now to the real part.

So you want me to change 
libmariadbclient-dev-compat to libmariadb-dev-compat? Can do that, but as said 
there won't be any real effect here :)

Or do you also want to change the (effective) default-libmysqlclient-dev 
build-dep, too? That should probably also work?
The resulting libreoffice-sdbc-mysql at least ends up with a dependency on 
libmariadb3 anyway.
Note LO used mysql_config so needs to compat thingies.[1]

Regards,

Rene

Bug#974220: libreoffice-writer: Double paste in Writer

[Rene Engelhard]

severity 974220 normal

tag 974220 + unreproducble

tag 974220 + moreinfo

thanks


Hi

Am 11.11.20 um 15:06 schrieb Claudio Ferreira Filho:
> Severity: important

As for your other bug,  this is IMHO not "important".


> When I copy anything (from browser, terminal or other application) and paste 
> in
> Writer, it paste duplicated.

Tried it with konsole and konqueror (as you use KDE) and with firefox to
try a non-KDE program.

> Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
TAINT_UNSIGNED_MODULE

> [...]

> ii  gstreamer1.0-libav 1:1.18.1-dmo1
> ii  gstreamer1.0-plugins-bad   1:1.18.1-dmo2
> ii  gstreamer1.0-plugins-base  1.18.1-dmo1
> ii  gstreamer1.0-plugins-good  1.18.1-dmo1
> ii  gstreamer1.0-plugins-ugly  1:1.18.1-dmo1

Oh my.

I thought about some x11 vs. wayland difference but a) my VM says x11
anyway and b) it looks like you use drivers outside of Debian for some
graphic chips of a company I am not going to name... which apparently
then forces x11 anyway.

Long story short: works here.


Just thinking out loud: Some extra clipboard stuff or stuff doing
something with the clipboard running? But then it might also happen on
the context menu...


Regards,


Rene

Bug#974421: Wrong title

[Rene Engelhard]

retitle 974421 TexMaths 0.48.2 not working in Debian unstable

tag  974421 + moreinfo

tag 974421 + unreproducible

thanks


Hi,

Am 11.11.20 um 17:27 schrieb g.l. gragnani:
> Of course, title should read:
> TexMaths 0.48.2 NOT working in Debian unstable
>
You could have retitled it yourself


Anyways, replying to this mail since the first one (apparently due to
the attachement, one could have written the error message as text, maybe
then it wouldn't have been caught by spam measures):

> The last version of TexMaths (0.48.2) does not work with the packages 
> provided by Debian.

Works fine here. sid VM. TexMaths 0.48.2 from the homepage.

clicked the "pi icon", entered \int_0^1 x^2 + \frac{1}{2} -> LaTeX. I do get 
the expected integral.

Maybe you should decribe what exactly does not work?

> Instead, by using the deb packages provided by libreoffice.org all work as 
> expected.

libreoffice.org has no "deb packages".
It has stuff put out of the build system into something which happens to be a 
container in "deb" format without following standards,
I won't call that packages.


Regards,

Rene

Bug#974345: libreoffice-writer: shortcut keys don't work

[Rene Engelhard]

tag 974345 + moreinfo

tag 974345 + unreproducible

severity 974345 normal

thanks

Hi,

Am 11.11.20 um 15:17 schrieb Claudio Ferreira Filho:
>  Severity: important

Sorry, no.


|important|
a bug which has a major effect on the usability of a package,
without rendering it completely unusable to everyone.
|normal|
the default value, applicable to most bugs.

How does this have "a major effect on the usability of a package"? One
could just click the buttons?

> Working in my text, I give a insight that all shortcut keys, like (B)old,
> (I)talic, ..., aren't working.

In my de_DE env:

Ctrl-Shift-F -> Fett (bold)

Ctrl-I -> Kursiv (italic)

(yeah, a bit inconsistent, but probably some MS Office "compatibility"...)

Ctrl-U -> Unterstrichen (underline)

just works.


Now trying pt_BR.

Tooltip of the N,I,S buttons say:

Ctrl-B -> Negrito

Ctrl-I -> Itálico

Ctrl-U -> Sublinhado

And yes, that works for me. Uptodate sid VM under KDE.


Regards,


Rene

Bug#973909: libreoffice-impress: crash when exiting presentation mode

[Rene Engelhard]

Hi,

Am 08.11.20 um 11:26 schrieb Heinrich Schuchardt:
> On 08.11.20 10:20, Rene Engelhard wrote:
>> Hi,
>>
>> Am 07.11.20 um 19:11 schrieb Rene Engelhard:
>>> Am 07.11.20 um 10:12 schrieb Heinrich Schuchardt:
>>>> Everytime I leave the LibreOffice Impress presentation mode by pressing
>>>> the ESC key the application crashes:
>>> [...]
> With
>
> libreoffice-impress_7.0.4~rc1~git20201107-1_amd64.deb
> libreoffice-draw_7.0.4~rc1~git20201107-1_amd64.deb
> libreoffice-core_7.0.4~rc1~git20201107-1_amd64.deb
>
> the reported crash in LibreOffice Impress is gone.

Thanks for confirming.

Regards,


Rene

Bug#973909: libreoffice-impress: crash when exiting presentation mode

[Rene Engelhard]

Hi,

Am 07.11.20 um 19:11 schrieb Rene Engelhard:
> Am 07.11.20 um 10:12 schrieb Heinrich Schuchardt:
>> Everytime I leave the LibreOffice Impress presentation mode by pressing
>> the ESC key the application crashes:
> In a just upgraded amd64 testing VM (inside KDE):
>
> 1. Start loimpress
>
> 2. F5 with that empty document
>
> 3. ESC
>
> Closes and I am fine in Impress again. No crash.

Built a current snapshot anyway:


deb [trusted=yes]
http://people.debian.org/~rene/libreoffice/7.0/snapshots ./


(not signed, so [trusted=yes])


Would you confirm it fixes it?


Regards,


Rene

Bug#973909: libreoffice-impress: crash when exiting presentation mode

[Rene Engelhard]

tag 973909 + unreproducible

tag 973909 + moreinfo

thanks


Hi,


Am 07.11.20 um 10:12 schrieb Heinrich Schuchardt:
> Everytime I leave the LibreOffice Impress presentation mode by pressing
> the ESC key the application crashes:

In a just upgraded amd64 testing VM (inside KDE):

1. Start loimpress

2. F5 with that empty document

3. ESC

Closes and I am fine in Impress again. No crash.


Regards,


Rene

Bug#973909: libreoffice-impress: crash when exiting presentation mode

[Rene Engelhard]

Hi,

Am 07.11.20 um 10:39 schrieb Heinrich Schuchardt:
> The error does not occur with the LibreOffice 7.0 daily build:
You know what "daily builds" mean? Obviously not, it's a build from the
current development tree.
> https://dev-builds.libreoffice.org/daily/libreoffice-7-0/Linux-rpm_deb-x86_64@86-TDF/2020-11-06_03.36.20/libreoffice-7-0~2020-11-06_03.36.20_LibreOfficeDev_7.0.4.0.0_Linux_x86-64_deb.tar.gz



  
^

                                                                     
                                                                       
                                                                       
        7.0.4

> So, please, upgrade the package.

To what? Some random snapshot?

Definitely not.


libreoffice-7-0 is what will be 7.0.4 in December.[1]

And yes, then it will be updated.

Actually 7.0.4 is what will be in bullseye proper.


Regards,


Rene


[1] https://wiki.documentfoundation.org/ReleasePlan/7.0#7.0.4_release

Bug#973682: libreoffice-common: bash-completion for .pdf files

[Rene Engelhard]

tag 973682 + pending

thanks


Hi,

Am 03.11.20 um 09:34 schrieb Félix Sipma:
> As libreoffice-pdfimport functionality has been merged in the main 
> packages, it would be nice if pdf filenames could be completed with 
> bash-completion.
>
> "$ libreoffice " would list .pdf files in addition to .doc, .docx, 
> .odt, .txt, .jpg, etc.

... for libreoffice and lodraw, yes.

https://cgit.freedesktop.org/libreoffice/core/commit/?id=8ef56c7cb4008c6290da82b305ec2deefc8d94d5


Will be in 7.1. (Maybe I#öö backport it for the 7.0.x Debian packages.)


Regards,


Rene

Bug#921178: Re: Bug#940914: uno-libs3: Segfault on launch in cppu::_copyConstructAnyFromData

[Rene Engelhard]

Hi,

Am 03.11.20 um 06:35 schrieb Rene Engelhard:
>> As for reproduction, I believe the easiest is to grab the Debian live
>> CD image and run it in qemu -kvm, and it will reproduce. It does for
>> me. If you can't, please let me know.
> Ah, Live?
>
> Does it only happen in Live and not in "real" systems?
>
> Will try

Just works fine on debian-live-10.6.0-amd64-gnome.iso


Regards,


Rene

Bug#921178: Re: Bug#940914: uno-libs3: Segfault on launch in cppu::_copyConstructAnyFromData

[Rene Engelhard]

Hi,

Am 02.11.20 um 23:30 schrieb Witold Baryluk:
> I did provide stack traces for example in February 2019.
>
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=921178
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=940914

True, after which I said I simply can't reproduce it.

> There was zero response from the maintainer, i.e. what other
> information is required.

That is demonstratablly completely untrue.

I did reply to the bug, didn't I? And tagged it + unreproducible.


What is needed: Obviously telling circumstances when it happens.

Backtraces are good, but to make upstream debug it one probably needs to
tell them when it might happen, too

(and to check whether it does not happen anymore.)


And that is totally unclear.

> As for reproduction, I believe the easiest is to grab the Debian live
> CD image and run it in qemu -kvm, and it will reproduce. It does for
> me. If you can't, please let me know.

Ah, Live?

Does it only happen in Live and not in "real" systems?

Will try


Regards,


Rene

Bug#940914: uno-libs3: Segfault on launch in cppu::_copyConstructAnyFromData

[Rene Engelhard]

Hi,

to answer myself:

Am 02.11.20 um 12:14 schrieb r...@rene-engelhard.de:
> Am 2. November 2020 10:23:49 MEZ schrieb Witold Baryluk 
> :
>> I wasn't able to use libreoffice for almost 2 years on Debian, on
>> multiple machines.
> Then you should have provided needed info in those 2 years? It's not tagged 
> unreproducible, moreinfo just for fun. ;-)
>
> Most people do not have your problem as otherwise there would be far more 
> reports...
> [...]
> One idea: What happens if you are not collecting Translations, Help, 
> Dictionaries, Thesauri and Hyphenation patterns you probably won't need all 
> and reduce it to stuff you need?
>
> I could imagine (yeah, would be a bug, but..) that bring a problem.

Hmm, no, works here. (pure sid chroot + apt install libreoffice + apt
install mythes + aptitude and installing hunspell-* and myspell-* with
conflict resolution

Regards,

Rene

Bug#973517: libreoffice-canzeley-client: please depend on libreoffice-sdbc-mysql instead of transitional libreoffice-mysql-connector

[Rene Engelhard]

Package: libreoffice-canzeley-client
Version: 0.5.1-4
Severity: wishlist

Hi Mechtilde,

libreoffice-mysql-connector is (since long) a transitional package for
libreoffice-sdbc-mysql (since it's not an extension anymore but
integrated into LO proper.):

# apt-cache show libreoffice-mysql-connector
Package: libreoffice-mysql-connector
Source: libreoffice
Version: 1:7.0.3-1
Installed-Size: 216
Maintainer: Debian LibreOffice Maintainers 
Architecture: amd64
Depends: libreoffice-sdbc-mysql
Description: transitional package for MariaDB/MySQL Connector extension for 
LibreOffice
Description-md5: f67e8b039d42be412b79ebf1381a0f85
Homepage: http://www.libreoffice.org
Tag: role::shared-lib
Section: misc
Priority: optional
Filename: 
pool/main/libr/libreoffice/libreoffice-mysql-connector_7.0.3-1_amd64.deb
Size: 198196
MD5sum: 63c1c27fcd8ec3c336a9cdf94b8720f7
SHA256: d6e335dd242c3bace5fc45a26408721d3add9ee0bd6dcab0dcfedf7387143bd1

So please make the libreoffice-mysql-connector alternative use
libreoffice-sdbc-mysql.

Since I remove the transitional package for 7.1 this will get "serious"
problem when 7.1 will enter Debian after the bullseye freeze.

(See
https://release.debian.org/transitions/html/auto-libreoffice.html[1])

Regards,

Rene

[1] The l10n stuff will solve itself magically, for alphas I don't build
translations.

Bug#966087: New info

[rene . engelhard]

severity 960087 serious
retitle 960087 libreoffice-writer: Cannot save file: "General input/output 
error" due to missing librdf0
thanks

Hi,

I almost wanted to answer (in a more verbose form) that there is no missing 
dependency...

Am 29. Oktober 2020 01:15:50 MEZ schrieb Emmanuel Oliveros :
(...) libraptor2-0* librasqal3* librdf0* (...)

But those are actually missing... - *on 32 bit only* (thus also e.g. on 
armhf...). (Due to technical details I won't annoy you with...)

>(...). So the source of the problem is the lack of one or more of the above 
>packages, I don't
>know which ones exactly.

Jup, see above. 

> I hope this information helps to solve the
>problem

Jup, thanks.

Will fix ASAP and if it's in testing it will be backported to buster-backports.

Regards

Rene

-- 
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.

Bug#972280: Libreoffice: when adwaita-dark controls used, buttons are not visible anymore

[Rene Engelhard]

forwarded 972280
https://bugs.documentfoundation.org/show_bug.cgi?id=126933


tag 972280 + upstream

thanks


Hi,

On 15.10.20 20:48, Pavlos Ponos wrote:
> Package: libreoffice
> Version: 1:7.0.2-2
> Severity: important

Oh my.

My humble opinion but this only happens when

a) using something not default

b) using buttons for something which should be done by styles..

and one can live with this and this not "important". But anyways, won't
argue.

> When using adwaita-dark controls, buttons for text formatting are not visible 
> anymore. When switching back to debian's default, everyt

.. hing works?

> Please consider adjusting buttons when black themes used, otherwise it's 
> almost impossible to find the button you are looking for.
>
> Screenshot to follow.

This is upstreams job, and actually there is
https://bugs.documentfoundation.org/show_bug.cgi?id=126933
 ... Follow
any status there.

Regards,


Rene

Bug#966087: LO saving failure

[Rene Engelhard]

[ also sending to the bug ]

Hi,

Am 13.10.20 um 19:41 schrieb Sulyok Attila:
> I prepared a bug report see below. I did not submit it, because I
> found the same bug reported under #966087.
>
> Have you any idea how to get free from this bug ?
>
As said already, I need info.


It works in a i386 test VM (on a amd64 host with KVM of course, so if
it's something only exhibiting on real (ld?) i386 hardware) I am not
able to test this.


Note also the buildlog
(https://buildd.debian.org/status/fetch.php?pkg=libreoffice=i386=1%3A7.0.2-2=1602499300=1)
doesn't show a test failure for saving stuff if I didn't overlook anything.

(Yes, it fails due to some numeric thingies. As upstream doesn't care
about 32bit at all... Thus also the failure is not deemed fatal,
otherwise we never would get a updated version into anything...)

Regards,


Rene

Bug#972043: libreoffice: 1:6.1.5-1 -> 1:7.0.2-1 upgrade fails

[Rene Engelhard]

Hi,

Am 11.10.20 um 21:12 schrieb Jessica Clarke:
>> Preparing to unpack .../09-libreoffice-common_1%3a7.0.2-1_all.deb ...
>> dpkg-maintscript-helper: error: file 
>> '/usr/lib/libreoffice/share/registry/math.xcd' not owned by package 
>> 'libreoffice-common:all'
>> dpkg-maintscript-helper: error: directory 
>> '/usr/lib/libreoffice/share/registry' contains files not owned by package 
>> libreoffice-common:all, cannot switch to symlink
>> dpkg: error processing archive 
>> /tmp/apt-dpkg-install-yFAjDA/09-libreoffice-common_1%3a7.0.2-1_all.deb 
>> (--unpack):
>>  new libreoffice-common package pre-installation script subprocess returned 
>> error exit status 1
>> [...]
>> debian:~ jrtc27% sudo dpkg -S /usr/lib/libreoffice/share/registry/math.xcd
>> libreoffice-math: /usr/lib/libreoffice/share/registry/math.xcd

Sigh. I hate this dpkg bullshit.

(And so far for testing this in experimental first.)


The upgrade worked before this symlink was added due to #969653 (and
upstream not hounouring their own config) before I added this symlink. :(

Looks like I need a Conflicts: against pre-7.0 packages containing stuff
in /usr/lib/libreoffice/share/registry ...


Regards,


Rene

Bug#970688: rm: /lib/i386-linux-gnu/libtinfo.so.6: version `NCURSES6_TINFO_6.2.current' not found (required by /lib/i386-linux-gnu/libncurses.so.6)

[Rene Engelhard]

Hi,

Am 21.09.20 um 18:34 schrieb Sven Joachim:
> Control: reassign -1 cowdancer
> Control: forcemerge 970555 -1
>
> On 2020-09-21 17:53 +0200, Rene Engelhard wrote:
>
>> Package: libtinfo6
>> Version: 6.2+20200918-1
>> Severity: serious
>>
>> Hi,
>>
>> in a (dist-|cowbuilder ) upgrade  of my i386 chroot:
>>
>> Preparing to unpack .../libncursesw6_6.2+20200918-1_i386.deb ...
>> Unpacking libncursesw6:i386 (6.2+20200918-1) over (6.2-1) ...
>> Preparing to unpack .../libncurses6_6.2+20200918-1_i386.deb ...
>> Unpacking libncurses6:i386 (6.2+20200918-1) over (6.2-1) ...
>> rm: /lib/i386-linux-gnu/libtinfo.so.6: version `NCURSES6_TINFO_6.2.current' 
>> not found (required by /lib/i386-linux-gnu/libncurses.so.6)
>> dpkg: error while cleaning up:
>>  rm command for cleanup subprocess returned error exit status 1
>> dpkg-split: /lib/i386-linux-gnu/libtinfo.so.6: version 
>> `NCURSES6_TINFO_6.2.current' not found (required by 
>> /lib/i386-linux-gnu/libncurses.so.6)
>> rm: /lib/i386-linux-gnu/libtinfo.so.6: version `NCURSES6_TINFO_6.2.current' 
>> not found (required by /lib/i386-linux-gnu/libncurses.so.6)
>> dpkg: error processing archive 
>> /var/cache/apt/archives/libtinfo6_6.2+20200918-1_i386.deb (--unpack):
>>  rm command for cleanup subprocess returned error exit status 1
>> Errors were encountered while processing:
>>  /var/cache/apt/archives/libtinfo6_6.2+20200918-1_i386.deb
>> E: Sub-process /usr/bin/dpkg returned an error code (1)
>> I: Copying back the cached apt archive contents
>> I: unmounting /home filesystem
>> I: unmounting dev/ptmx filesystem
>> I: unmounting dev/pts filesystem
>> I: unmounting dev/shm filesystem
>> I: unmounting proc filesystem
>> I: unmounting sys filesystem
>> E: pbuilder update failed
>> E: could not update with cowdancer, try --no-cowdancer-update option
> Please follow that advice, see #970555 for details.

I've seen that bug in the meanwhile.


But interestingly it also failed with;

$ cowbuilder login --basepath  etc.
[...]
# apt update
# apt dist-upgrade

[1] (which I often do) which wouldn't mean not doing a cowdancer update
would have worked around it? Or do I miss something?


Regards,


Rene


[1] yes, that doesn't retain the upgrade but this was a one-shot build
for an upstream anyway.

Bug#970688: rm: /lib/i386-linux-gnu/libtinfo.so.6: version `NCURSES6_TINFO_6.2.current' not found (required by /lib/i386-linux-gnu/libncurses.so.6)

[Rene Engelhard]

Package: libtinfo6
Version: 6.2+20200918-1
Severity: serious

Hi,

in a (dist-|cowbuilder ) upgrade  of my i386 chroot:

$ sudo cowbuilder --update --basepath /var/cache/pbuilder/base.cow.i386/ 
--bindmounts /home
I: Copying COW directory
I: forking: rm -rf /var/cache/pbuilder/build/cow.26407
I: forking: cp -al /var/cache/pbuilder/base.cow.i386 
/var/cache/pbuilder/build/cow.26407
I: unlink for ilistfile /var/cache/pbuilder/build/cow.26407/.ilist failed, it 
didn't exist?
I: Invoking pbuilder
I: forking: pbuilder update --bindmounts /home --buildplace 
/var/cache/pbuilder/build/cow.26407 --mirror http://deb.debian.org/debian/ 
--distribution sid --no-targz --internal-chrootexec 'chroot 
/var/cache/pbuilder/build/cow.26407 cow-shell'
W: /root/.pbuilderrc does not exist
I: Running in no-targz mode
I: Current time: Mon Sep 21 17:48:08 CEST 2020
I: pbuilder-time-stamp: 1600703288
I: copying local configuration
W: --override-config is not set; not updating apt.conf Read the manpage for 
details.
I: mounting /proc filesystem
I: mounting /sys filesystem
I: creating /{dev,run}/shm
I: mounting /dev/pts filesystem
I: redirecting /dev/ptmx to /dev/pts/ptmx
I: Mounting /home
I: policy-rc.d already exists
I: Refreshing the base.tgz
I: upgrading packages
Get:1 http://deb.debian.org/debian sid InRelease [146 kB]
Get:2 http://deb.debian.org/debian sid/main i386 Packages.diff/Index [27.9 kB]
Ign:2 http://deb.debian.org/debian sid/main i386 Packages.diff/Index
Get:3 http://deb.debian.org/debian sid/main i386 Packages [8322 kB]
Fetched 8496 kB in 4s (1935 kB/s)
Reading package lists...
I: Obtaining the cached apt archive contents
Reading package lists...
Building dependency tree...
Reading state information...
Calculating upgrade...
The following packages will be upgraded:
  apt aptitude aptitude-common bash binutils binutils-common 
binutils-i686-linux-gnu bsdutils cpp cpp-10 debianutils g++ g++-10 gcc gcc-10 
gcc-10-base gcc-9-base
  libapt-pkg6.0 libasan6 libatomic1 libbinutils libblkid1 libc-bin libc-dev-bin 
libc6 libc6-dev libcc1-0 libcrypt-dev libcrypt1 libctf-nobfd0 libctf0 
libdebconfclient0
  libgcc-10-dev libgcc-s1 libgdbm-compat4 libgdbm6 libgnutls30 libgomp1 libitm1 
libmount1 libmpc3 libncurses6 libncursesw6 libp11-kit0 libquadmath0 libseccomp2
  libsmartcols1 libsqlite3-0 libstdc++-10-dev libstdc++6 libsystemd0 libtinfo6 
libubsan1 libudev1 libuuid1 libxapian30 libzstd1 linux-libc-dev mount 
ncurses-base
  ncurses-bin sysvinit-utils util-linux
63 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 0 B/69.4 MB of archives.
After this operation, 584 kB of additional disk space will be used.
debconf: delaying package configuration, since apt-utils is not installed
(Reading database ... 12421 files and directories currently installed.)
Preparing to unpack .../debianutils_4.11.1_i386.deb ...
Unpacking debianutils (4.11.1) over (4.11) ...
Setting up debianutils (4.11.1) ...
(Reading database ... 12421 files and directories currently installed.)
Preparing to unpack .../archives/bash_5.0-7_i386.deb ...
Unpacking bash (5.0-7) over (5.0-6) ...
Setting up bash (5.0-7) ...
update-alternatives: using /usr/share/man/man7/bash-builtins.7.gz to provide 
/usr/share/man/man7/builtins.7.gz (builtins.7.gz) in auto mode
(Reading database ... 12421 files and directories currently installed.)
Preparing to unpack .../bsdutils_1%3a2.36-3_i386.deb ...
Unpacking bsdutils (1:2.36-3) over (1:2.35.2-9) ...
Setting up bsdutils (1:2.36-3) ...
(Reading database ... 12421 files and directories currently installed.)
Preparing to unpack .../libcrypt-dev_1%3a4.4.17-1_i386.deb ...
Unpacking libcrypt-dev:i386 (1:4.4.17-1) over (1:4.4.16-1) ...
Preparing to unpack .../libc6-dev_2.31-3_i386.deb ...
Unpacking libc6-dev:i386 (2.31-3) over (2.31-2) ...
Preparing to unpack .../libc-dev-bin_2.31-3_i386.deb ...
Unpacking libc-dev-bin (2.31-3) over (2.31-2) ...
Preparing to unpack .../libcrypt1_1%3a4.4.17-1_i386.deb ...
Unpacking libcrypt1:i386 (1:4.4.17-1) over (1:4.4.16-1) ...
Setting up libcrypt1:i386 (1:4.4.17-1) ...
(Reading database ... 12424 files and directories currently installed.)
Preparing to unpack .../0-linux-libc-dev_5.8.10-1_i386.deb ...
Unpacking linux-libc-dev:i386 (5.8.10-1) over (5.7.6-1) ...
Preparing to unpack .../1-libcc1-0_10.2.0-9_i386.deb ...
Unpacking libcc1-0:i386 (10.2.0-9) over (10.1.0-6+b1) ...
Preparing to unpack .../2-libctf0_2.35-3_i386.deb ...
Unpacking libctf0:i386 (2.35-3) over (2.34.90.20200706-1) ...
Preparing to unpack .../3-libctf-nobfd0_2.35-3_i386.deb ...
Unpacking libctf-nobfd0:i386 (2.35-3) over (2.34.90.20200706-1) ...
Preparing to unpack .../4-binutils-i686-linux-gnu_2.35-3_i386.deb ...
Unpacking binutils-i686-linux-gnu (2.35-3) over (2.34.90.20200706-1) ...
Preparing to unpack .../5-libbinutils_2.35-3_i386.deb ...
Unpacking libbinutils:i386 (2.35-3) over (2.34.90.20200706-1) ...
Preparing to unpack .../6-binutils-common_2.35-3_i386.deb ...
Unpacking binutils-common:i386 (2.35-3) over