Bug#964780: libreoffice-writer crashes on startup after upgrade to 1:7.0.0~rc1-5

[Rene Engelhard]

Hi,

Am 15.07.20 um 16:10 schrieb Rogério Brito:

> I tried to find bug reports about this, found only this one and expected to
> find more, waited a few days, and this is still the only problem reported so
> far, which I found strange.

Why? That just shows it works in most cases, and breaks in "special" ones. And 
of course if it works in most cases people don't report a bug ;-)

> Nevertheless, what I am seeing may or may not be related to the bug that
> Thorsten reported (in which case a new bug should be filed, of course), but
> removing ~/.config/.libreoffice and invoking libreoffice on the command line

Given Thorsten says it works with a clean profile, how should it? You
said you removed it and got *AN OTHER* error.

Can "bugs" please be kept separate?

> briefly shows the splash screen and, then, shows the following message on my
> terminal:
>
> ,
> | $ libreoffice 
> | : CommandLine Error: Option 'polly' registered more than once!
> | LLVM ERROR: inconsistency in registered CommandLine options
> `

I'd have a look what causes this. Wherever this "polly" "command-line"
option is set.

LO doesn't set it.


(And only a subset of LO is built with clang but not linked with LLVM or
otherwise using it, so

that can't be it either, especially since googling for it (and I think
there was a similar bug months ago with an other option) predates 7.0s
clang usage)

Regards,

Rene

Bug#965027: 回复：Bug#965027: libreoffice-impress: libreoffice impress crashes when dragging image inserted

[Rene Engelhard]

[ please
  a) use proper mail quoting, and don't fullquote
  b) Cc the bug itherwise stuff doesn't get recorded
]

Hi,

On Wed, Jul 15, 2020 at 02:14:33AM +0800, Junyue Wang 王寯越 wrote:
>As you see in the screenshot, an image was inserted in a slide, if I click
>and try to drag the image, the libreoffice will crash, and a file recovery
>dialog will come out saying: due to accidental error, libreoffice crashed.
>All files you are working on will be saved. Next time libreoffice starts
>your files will be recovered automatically. 
>The output of terminal is:
>(soffice:32472): GLib-GObject-CRITICAL **: 14:02:47.310:
>g_object_get_data: assertion 'G_IS_OBJECT (object)' failed

You did not even answer my question.

Please try a uptodate version.

I am not going to deal with 6.1.5 on mips64el.
[ And: There's no mips64el machine at hand with GUI to even be able to try
(and no sane way to have it emulated). ]

Regards,

Rene

Bug#955271: libreoffice-common: AppArmor profile blocks gpg's tofu.db, causes hang opening Options

[Rene Engelhard]

user pkg-apparmor-t...@lists.alioth.debian.org

usertag - buggy-profile
thanks

Hi,

Am 14.07.20 um 17:13 schrieb John Scott:
> I think there's a misunderstanding. I realize with no GnuPG 2
> abstraction it's
> not your job to work around this. The usertag 'buggy-profile' merely 
> indicates 
> that it is an issue caused by AppArmor, not that you're responsible to fix 
> it. 
> Please see their usertag definitions [1].

Except that it says "buggy-profile". That's enough to have me not want
it as a tag. There is no buggy profile here.

It simply doesn't allow non-default config. AppArmor allows only
explicitely allowed stuff, and you can't simply allow anything as that
would defeat the sense of apparmor.

And especially for gpg which is security-sensitive

So it's the job or whoever set tofu as trust model for whatever reason
to fix it ;-)

Regards,


Rene

Bug#965027: libreoffice-impress: libreoffice impress crashes when dragging image inserted

[Rene Engelhard]

tag 965027 + moreinfo

thanks

Hi,

Am 14.07.20 um 18:11 schrieb junyue:
> After inserted an image into a slide in libreoffice impress, dragging the 
> image
> with the mouse will cause libreoffice impress to crash and exit, and then asks
> if want to recover the file. I have tried many times, it happens every time.

Please try with a non-ancient version?

7.0.0 rcX is not available yet for buster, but 6.4.5-1 is in
buster-backports.

(stable won't get any updates for this - except for RC bugs or real
important issues or security updates.)

Regards,


Rene

> Thanks!
>
>
>
> -- System Information:
> Debian Release: bullseye/sid
Erm? Then it should say "buster"
>   APT prefers stable-updates
>   APT policy: (500, 'stable-updates'), (500, 'stable')

... if you use stable.

What are you using really? At least your packages are stable, but...

> Architecture: mips64el (mips64)


Wow :)

Regards,

Rene

Bug#964944: libreoffice-l10n-zh-cn: language pack not selectable in libreoffice settings

[Rene Engelhard]

reassign 964944
libreoffice-l10n-en-gb,libreoffice-l10n-en-za,libreoffice-l10n-pa-in,libreoffice-l10n-pt-br,libreoffice-l10n-zh-cn,libreoffice-l10n-zh-tw

found 964944 1:7.0.0~alpha1-1

severity 964944 grave

thanks

Hi,

Am 13.07.20 um 05:20 schrieb Wenbin Lv:
> zh-cn (and zh-tw) languages are not selectable in libreoffice settings
> fter upgrading to 7.0. By comparing with language packs of other
> languages, I notice that some autogenerated commands are missing in
> postinst script of libreoffice-l10n-zh-{cn,tw}. Manually running the
> following commands fixes the problem:
[...]

Hmm. All that is - as you say - autogenerated - and while cjk etc was
missing in some versions that is added, too.


But looking at debian/rules right now:

    # create .ucf files for libreoffice-l10n-*. First generic ones
    # libreoffice-l10n.ucf.in, but there also are CJK/CTL specific
    # files, too...
    for i in $(filter-out en-US,$(LANGPACKISOS)); do \
    cat debian/libreoffice-l10n.ucf.in \
    | sed -e "s/\@ISO\@/$$i/g" \
    > debian/libreoffice-l10n-$$i.ucf; \
    if [ -f instdir/share/registry/ctl_$$i.xcd ]; then \
    echo "/usr/lib/libreoffice/share/.registry/ctl_$$i.xcd
/etc/libreoffice/registry/ctl_$$i.xcd" \
    >> debian/libreoffice-l10n-$$i.ucf; \
    fi; \
    if [ -f instdir/share/registry/ctlseqcheck_$$i.xcd ]; then \
    echo
"/usr/lib/libreoffice/share/.registry/ctlseqcheck_$$i.xcd
/etc/libreoffice/registry/ctlseqcheck_$$i.xcd" \
    >> debian/libreoffice-l10n-$$i.ucf; \
    fi; \
    if [ -f instdir/share/registry/cjk_$$i.xcd ]; then \
    echo "/usr/lib/libreoffice/share/.registry/cjk_$$i.xcd
/etc/libreoffice/registry/cjk_$$i.xcd" \
    >> debian/libreoffice-l10n-$$i.ucf; \
    fi; \
    done

it occurs to me that you don't get this since it's written e.g. into a
libreoffice-l10n-zh-TW.ucf file instead of a libreoffice-l10n-zh-tw.ucf
file...

Which also means xx_YY langpacks are affected...


Thanks for reporting, will fix.


Regards,


Rene

Bug#964780: libreoffice-writer crashes on startup after upgrade to 1:7.0.0~rc1-5

[Rene Engelhard]

Hi,

Am 10.07.20 um 16:44 schrieb Rene Engelhard:
> You write "crashes". I didn't see a crash in strace? You it actually
> crash and did you attach gdb as written in the reportbug message? Or did
> it fail to start? (That isn't a crash.)
Actually there's SIGSEGV at the end ...
>
> No idea whether it is related, but I see gazillions of stuff like
>
> 11267 14:00:25.991198 
> stat("/usr/lib/libreoffice/program/tech/units/indriya/AbstractConverter$Pair.class",
>  0x7f3a9fff8b80) = -1 ENOENT (Datei oder Verzeichnis nicht gefunden
> )
> 11267 14:00:25.991231 
> stat("/home/thaden/.config/libreoffice/4/user/uno_packages/cache/uno_packages/lu7352qashpo.tmp_/LanguageTool-4.8.oxt/tech/units/indriya/AbstractConvert
> er$Pair.class", 0x7f3a9fff8b80) = -1 ENOENT (Datei oder Verzeichnis nicht 
> gefunden)

but I wouldn't be surprised if that was because of those


> In a quick test in a clean VM writer still starts after LT 4.8 was
> installed, though.

.. and doesn't show the above.

Regards,


Rene

Bug#964780: libreoffice-writer crashes on startup after upgrade to 1:7.0.0~rc1-5

[Rene Engelhard]

severity 964780 important
tag 964780 + moreinfo
tag 964780 + unreproducible
thanks

On Fri, Jul 10, 2020 at 02:12:26PM +0200, Thorsten de Jong wrote:
> Package: libreoffice-writer
> Version: 1:7.0.0~rc1-5
> Severity: grave
> Justification: renders package unusable

Erm, no, how?

It _obviously_
- starts in a clean VM
- starts in autokpgtest. Which starts writer up a gazillion of times to
  check the UI.

>* What led up to the situation?
> Starting libreoffice-writer

It really hard to write a bit more?

You write "crashes". I didn't see a crash in strace? You it actually
crash and did you attach gdb as written in the reportbug message? Or did
it fail to start? (That isn't a crash.)

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

Not related, but:

I'll never undertsand why people do bullshit lile this. Especially
stable and testing.. (You are completely on unstable away, so there's no
point in this)

[ attached strace.log ]

No idea whether it is related, but I see gazillions of stuff like

11267 14:00:25.991198 
stat("/usr/lib/libreoffice/program/tech/units/indriya/AbstractConverter$Pair.class",
 0x7f3a9fff8b80) = -1 ENOENT (Datei oder Verzeichnis nicht gefunden
)
11267 14:00:25.991231 
stat("/home/thaden/.config/libreoffice/4/user/uno_packages/cache/uno_packages/lu7352qashpo.tmp_/LanguageTool-4.8.oxt/tech/units/indriya/AbstractConvert
er$Pair.class", 0x7f3a9fff8b80) = -1 ENOENT (Datei oder Verzeichnis nicht 
gefunden)

/usr/lib/libreoffice/program/tech/units/indriya/AbstractConverter$Pair.class
would be wrong in any case, sd the files would never be there.

How did you install LanguageTool (which is known to cause problems like
instability)? What happens if you remove it?

And why 4.8? There's 5.0.1 on languagetool.org? Maybe it has fixes?

In a quick test in a clean VM writer still starts after LT 4.8 was
installed, though.

What happens if you start in safe mode and/or move your
.config/libreoffice away and start with a clean profile?

Regards,

Rene

Bug#964459: libreoffice-kf5: [kf5] [dark theme] unreadable elements: button labels on welcome screen, names in dropdown font list

[Rene Engelhard]

forwarded 964459 https://bugs.documentfoundation.org/show_bug.cgi?id=133929
tag 964459 + upstream
thanks

Hi,

On Wed, Jul 08, 2020 at 12:53:14AM +1000, Thom wrote:
> LibreOffice with VCL plugin kf5 have unreadable button labels on welcome 
> screen sidebar (white text on light gray background) and fontnames in 
> dropdown font list (light gray text on white background) in Writer, Calc, etc.
> 
> LibreOffice with VCL plugin gtk-3 looks fine in same situation.

[libreoffice-kf5-7.0.0~rc1-1-start-screen.png (image/png, attachment)]

This is https://bugs.documentfoundation.org/show_bug.cgi?id=133929

[libreoffice-kf5-7.0.0~rc1-1-writer.png (image/png, attachment)]

For this there's various bugs possible:

https://bugs.documentfoundation.org/buglist.cgi?quicksearch=dark%20theme_id=1166282

ID  Product CompAssignee▲   Status▲ Resolution  Summary Changed
126933  LibreOffWriter  libreoffice-b...@lists.free...  UNCO--- 
LO Writer shows some Buttons almost Unreadable when using High Contrast Theme   
2020-03-16
131978  LibreOffUI  libreoffice-b...@lists.free...  UNCO--- 
With dark color theme spell checking dialog is unreadable   2020-04-23
133306  LibreOffWriter  libreoffice-b...@lists.free...  UNCO--- 
[Dark theme] Spell checker has wrong font foreground2020-05-25
133931  LibreOffCalclibreoffice-b...@lists.free...  UNCO--- 
KDE5/QT5 VCL & dark theme: Calc: every other function name in Function Wizard 
list is unreadable2020-06-27
103656  LibreOffUI  libreoffice-b...@lists.free...  NEW --- 
Read-only bar is unreadable when using dark theme   2020-06-12

for example

So, because you didn't follow the principle of one bug one bugreport -
what are we going to mark it as forwarded to

I'd say https://bugs.documentfoundation.org/show_bug.cgi?id=133929 but
that also would mean that this bug should be closed if that one is
closed regardless of your writer issue.

Regards,

Rene

Bug#964471: libreoffice-l10n-ru: error when configuring: cp: cannot create regular file '/etc/libreoffice/registry/Langpack-ru.xcd': No such file or directory

[Rene Engelhard]

tag 964471 - moreinfo

tag 964471 - unreproducible

Hi,

Am 07.07.20 um 23:05 schrieb Evgeny Kapun:
> On 07.07.2020 22:40, Rene Engelhard wrote:
>> Even that worked for me in said testing VM "upgraded" to unstable with
>> your apt-get --with-new-pkgs upgrade.
>>
>> libreoffice-l10n-de, libreoffice-l10n-ru and other LO packages were kept
>> back.
>
> After some testing, I found out that you also need to pass
> `--no-install-recommends`, as otherwise `Recommends: libreoffice-core
> (>> 1:7.0.0~rc1)` in libreoffice-l10n-ru prevents it from upgrading.
>
Ah, yes, indeed.

Regards,


Rene

Bug#964471: libreoffice-l10n-ru: error when configuring: cp: cannot create regular file '/etc/libreoffice/registry/Langpack-ru.xcd': No such file or directory

[Rene Engelhard]

On Tue, Jul 07, 2020 at 09:30:23PM +0200, Rene Engelhard wrote:
> Am 07.07.20 um 21:21 schrieb Evgeny Kapun:
> >> but how did you get into this situation?
> >
> > I've run `apt-get --with-new-pkgs upgrade`. This upgraded some
> > libreoffice packages including libreoffice-l10n-ru, but not
> > libreoffice-common because this would require it to remove
> > libreoffice-style-tango.
> 
> Aha. Will try.

Even that worked for me in said testing VM "upgraded" to unstable with
your apt-get --with-new-pkgs upgrade.

libreoffice-l10n-de, libreoffice-l10n-ru and other LO packages were kept
back.

Regards,

Rene

Bug#964471: libreoffice-l10n-ru: error when configuring: cp: cannot create regular file '/etc/libreoffice/registry/Langpack-ru.xcd': No such file or directory

[Rene Engelhard]

Hi,

Am 07.07.20 um 21:21 schrieb Evgeny Kapun:
>> but how did you get into this situation?
>
> I've run `apt-get --with-new-pkgs upgrade`. This upgraded some
> libreoffice packages including libreoffice-l10n-ru, but not
> libreoffice-common because this would require it to remove
> libreoffice-style-tango.

Aha. Will try.

And libreoffice-style-tango is required to be removed for a reason: It
simply is gone upstream :-)

> In the future, it seems wise to test plain `upgrade` and
> `--with-new-pkgs upgrade` in addition to dist-upgrade. 

Maybe. But here you DO want dist-upgrade. You are not supposed to keep
libreoffice-style-tango and the dependencies enforce that.

Regards,


Rene

Bug#964471: libreoffice-l10n-ru: error when configuring: cp: cannot create regular file '/etc/libreoffice/registry/Langpack-ru.xcd': No such file or directory

[Rene Engelhard]

tag 964471 + moreinfo
tag 964471 + unreproducible
thanks

Hi,

On Tue, Jul 07, 2020 at 08:59:26PM +0200, Rene Engelhard wrote:
> On Tue, Jul 07, 2020 at 08:40:54PM +0200, Rene Engelhard wrote:
> > Any upgrade I tried (and yes, also with -l10n-de/-help-de installed)
> > upgtaded libreoffice-common before the l10ns (and thus 
> > /etc/libreoffice/registry
> > iwas there at .postinst time)
> 
> And a clean testing VM dist-upgraded to unstable just now also worked.

(with -help-ru installed.)

> But anyways, as you should have already seen - added the same dependency in 
> git to
> anything having anything in /etc/libreoffice/registry.
> 
> Should fix it.

Also for (which I think you did, why can't people just do proper
upgrades, you "helpfully" didn't add your distro info added by reportbug in 
your report)
"let's install the unstable package on testing" scenarios.

Regards,

Rene

Bug#964471: libreoffice-l10n-ru: error when configuring: cp: cannot create regular file '/etc/libreoffice/registry/Langpack-ru.xcd': No such file or directory

[Rene Engelhard]

On Tue, Jul 07, 2020 at 08:40:54PM +0200, Rene Engelhard wrote:
> Any upgrade I tried (and yes, also with -l10n-de/-help-de installed)
> upgtaded libreoffice-common before the l10ns (and thus 
> /etc/libreoffice/registry
> iwas there at .postinst time)

And a clean testing VM dist-upgraded to unstable just now also worked.

But anyways, as you should have already seen - added the same dependency in git 
to
anything having anything in /etc/libreoffice/registry.

Should fix it.

Regards,
 
Rene

Bug#964471: libreoffice-l10n-ru: error when configuring: cp: cannot create regular file '/etc/libreoffice/registry/Langpack-ru.xcd': No such file or directory

[Rene Engelhard]

Hi,

On Tue, Jul 07, 2020 at 09:13:58PM +0300, Evgeny Kapun wrote:
> When upgrading Libreoffice, the following errors occur:
> 
> 
> Setting up libreoffice-l10n-ru (1:7.0.0~rc1-3) ...
> 
> Creating config file /etc/libreoffice/registry/Langpack-ru.xcd with new 
> version
> cp: cannot create regular file '/etc/libreoffice/registry/Langpack-ru.xcd': 
> No such file or directory
> dpkg: error processing package libreoffice-l10n-ru (--configure):
>  installed libreoffice-l10n-ru package post-installation script subprocess 
> returned error exit status 1
> dpkg: dependency problems prevent configuration of libreoffice-help-ru:
>  libreoffice-help-ru depends on libreoffice-l10n-ru; however:
>   Package libreoffice-l10n-ru is not configured yet.
> 
> dpkg: error processing package libreoffice-help-ru (--configure):
>  dependency problems - leaving unconfigured
> Errors were encountered while processing:
>  libreoffice-l10n-ru
>  libreoffice-help-ru
> 
> 
> This is apparently caused by /etc/libreoffice/registry not existing.

Interesting. I had that error once for other packages:

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

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

  * debian/patches/libreoffice.jar-pom.diff: add pom for new
libreoffice.jar
  * debian/patches/bigendian-ustrbuf-hxx.diff: add missing include
on bigendian architectures
  * debian/patches/skia-SkOpts_crc32.diff: add missing SkOpts_crc32
to fix skia build on arm

  * debian/control*in:
- make -librelogo, -sdbc-postgresql and -report-builder explicitly
  depend on libreoffice-common (>= 1:7.0.0~alpha~) as otherwise
  /etc/libreoffice/registry might not exist yet
[...]

but how did you get into this situation?

Any upgrade I tried (and yes, also with -l10n-de/-help-de installed)
upgtaded libreoffice-common before the l10ns (and thus /etc/libreoffice/registry
iwas there at .postinst time)

Regards,

Rene

Bug#964251: libreoffice-common: needs Breaks+Replaces against openclipart-libreoffice

[Rene Engelhard]

Hi,

Am 04.07.20 um 18:53 schrieb Rene Engelhard:
>> openclipart-libreoffice will probably need updates as well to no longer
>> ship these files (or rename them), it's probably easiest if you fix and
>> upload that QA maintained package, too.
> 
> No. I don't care, actually :-) That's why it is QA maintained.
> 
> 
> Yoju did the last QA uploads, you can do that too. (Actually it needs an
> update for the new
> 
> libreoffice-dev-gui anyways.)

Ah, well, just did that. (Needed to disable optipng since it hanged.)

Regards,

rene

Bug#964251: libreoffice-common: needs Breaks+Replaces against openclipart-libreoffice

[Rene Engelhard]

clone 964251 -1

reassign -1 openclipart-libreoffice

retitle -1 contains /usr/lib/libreoffice/share/gallery/shapes.* also in
libreoffice-common from LO 7.0.x onwards

thanks

Hi,

Am 04.07.20 um 15:51 schrieb Andreas Beckmann:
> because it tries to overwrite other packages files without declaring a
> Breaks+Replaces relation.
> [...]
[...]
> These three files are conflicting:
>
>   usr/lib/libreoffice/share/gallery/shapes.sdg
>   usr/lib/libreoffice/share/gallery/shapes.sdv
>   usr/lib/libreoffice/share/gallery/shapes.thm

I am not sure whether Replaces: is correct here. I mean besides that
both are names shapes.* and contain Shapes they don't have the same
stuff and thus aren't "replaced".

But probably there isn't a better field...

> openclipart-libreoffice will probably need updates as well to no longer
> ship these files (or rename them), it's probably easiest if you fix and
> upload that QA maintained package, too.

No. I don't care, actually :-) That's why it is QA maintained.


Yoju did the last QA uploads, you can do that too. (Actually it needs an
update for the new

libreoffice-dev-gui anyways.)


Regards,


Rene

Bug#963895: libuno-cppu3: circular dependency hell

[Rene Engelhard]

Hi,

Am 28.06.20 um 19:40 schrieb Rene Engelhard:
> One can argue about the "ure" here.
> 
> 
> This comes from the .symbols and is - if I remember right - just there
> to have C++ stuff using those libs have the appropriate runtime
> dependencies.  (We don't have some right now, one in the past was
> libreoffice-voikko, though.)
> 
> Because those libraries in itself are totally useless without ure.

So, and after I did what I did in expertimental one gets: (random
package choosen):

$ debdiff libreoffice-evolution_7.0.0~rc1~git20200627-1_amd64.deb
libreoffice-evolution_7.0.0~rc1~git20200628-1_amd64.deb
File lists identical (after any substitutions)

Control files: lines which differ (wdiff format)

Depends: libreoffice-base, libreoffice-common, libreoffice-core (=
[-1:7.0.0~rc1~git20200627-1),-] {+1:7.0.0~rc1~git20200628-1),+}
libebook-1.2-20, ucf (>= 0.8), libc6 (>= 2.14), libgcc-s1 (>= 3.0),
libglib2.0-0 (>= 2.38.0), libstdc++6 (>= 5), libuno-cppu3 (>=
4.4.0~alpha), libuno-cppuhelpergcc3-3 (>= 4.0.0~alpha), libuno-sal3 (>=
5.1.0~alpha), libuno-salhelpergcc3-3 (>= 1.4.0), [-uno-libs-private,
ure-] {+uno-libs-private+}
Version: [-1:7.0.0~rc1~git20200627-1-] {+1:7.0.0~rc1~git20200628-1+}

OK, -core/-common depend on ure anyway, but...

Regards,

Rene

Bug#963895: libuno-cppu3: circular dependency hell

[Rene Engelhard]

found 963895 1:7.0.0~beta2-2

severity 963895 minor

reassign 963895
libuno-cppu3,libuno-sal3,libuno-cppuhelpergcc3-3,libuno-salhelpergcc3-3,uno-libs3,ure

retitle 963895 circular dependencies between
libuno-cppu3,libuno-sal3,libuno-cppuhelpergcc3-3,libuno-salhelpergcc3-3,uno-libs3,ure

thanks


[ And again you did it. Again by accussing people of carelessness and
not thinking and by using the words "dependency hell". There is no
dependency "hell" here.

Didn't we already have this the last time you came up with a "bug" like
this? ]


Hi,

Am 28.06.20 um 17:56 schrieb Bill Allombert:
> Package: libuno-cppu3

If this was a circular dependency, why only filed on this one?

If you file "bugs", please some care.

> Version: 1:6.4.5~rc1-2

Dead.

There will only be a update to 6.4.5-1 final next week and then 6.4.x
will be dead. Unstable will get 7.0.0 rc1.

And I simply will not rush something like this in for a last 6.4.x
upload, no, sorry.

> Severity: important

Wrong. Please tell me how this fits into

--- snip ---

1 important  a bug which has a major effect on the usability of a
package, without rendering it completely unusable to everyone.

--- snip ---

How does it have "a major effect on the usability of a package"?

The use of this package is at runtime, where everything is straight.

> There is a circular dependency between libuno-cppu3, libuno-cppuhelpergcc3-3, 
> libuno-purpenvhelpergcc3-3, libuno-salhelpergcc3-3, uno-libs-private and ure:
>
> libuno-cppu3  :Depends: libuno-salhelpergcc3-3 (>= 1.4.0), ure
> libuno-cppuhelpergcc3-3   :Depends: uno-libs-private (= 1:6.4.5~rc1-2), 
> libuno-cppu3 (>= 4.4.0~alpha), libuno-salhelpergcc3-3 (>= 1.4.0), ure
Unfortunately the public libuno_cppuhelpergcc3.so.3 depends on private
libs. (uno-libs-private). What are you expecting? Not declare that
dependency? That would be a policy violation.
> libuno-purpenvhelpergcc3-3:Depends: libuno-cppu3 (>= 1.4.0), ure
> libuno-salhelpergcc3-3:Depends: ure

One can argue about the "ure" here.


This comes from the .symbols and is - if I remember right - just there
to have C++ stuff using those libs have the appropriate runtime
dependencies.  (We don't have some right now, one in the past was
libreoffice-voikko, though.)

Because those libraries in itself are totally useless without ure.

> uno-libs-private  :Depends: libuno-cppu3 (>= 1.4.0), 
> libuno-salhelpergcc3-3 (>= 1.4.0), ure
> ure   :Depends: uno-libs-private (= 1:6.4.5~rc1-2), libuno-cppu3 (>= 
> 4.4.0~alpha), libuno-cppuhelpergcc3-3 (>= 4.0.0~alpha), 
> libuno-purpenvhelpergcc3-3 (>= 1.4.0), libuno-salhelpergcc3-3 (>= 3.6.0~beta)

These are simply not discussable since that are the actual library
dependencies.

The nature of private libs is that they are private.

One might merge uno-libs-private into ure, but I don't think that makes
sense.

Neither does merging all those libuno* somewhere else (packages of
public libraries should be named to that they change if the SONAME
changes, and lintian correctly complains about
package-name-not-matching-soname or however it it called.)

> Complex circular dependencies are known to cause problems during upgrade,

If said stuff is used during the upgrade.


None of these is. If apt broke the cycle up during update so what? After
the upgrade they will be present as intended.


Regards,


Rene

Bug#962903: libreoffice: Fails to open any PDF ("This PDF file is encrypted and can't be opened.")

[Rene Engelhard]

tag 962903 - wontfix
tag 962903 + patch
thanks

Hi,

Am 20.06.20 um 14:19 schrieb Rene Engelhard:
> Am 20.06.20 um 14:11 schrieb Rene Engelhard:
>> 2575  19:27:45.464196 openat(AT_FDCWD, "/tmp/test-tmp-ametzler/Qqf3SE", 
>> O_RDONLY) = -1 EACCES (Permission denied)
>> I wonder about that /tmp/test-tmp-ametzler.
>>
>>
>> The apparmor rules might just allow /tmp/*, not /tmp/something/*.
> 
> profile libreoffice-xpdfimport /usr/lib/libreoffice/program/xpdfimport {
>   #include 
> 
>   owner /tmp/*  r, #Seems to need to read file created
> with pattern /tmp/RR
>   owner /tmp/lu**   rw,    #makes files like
> luR.tmp/lub.tmp where R is random
>    #Note, usually it's lub or luc, don't
> know why.
> [...]

Sigh. Apparently #debian-devel disagrees here and says the profile is
buggy (which I do not agree with), but thankfully the fix should be easy:

diff --git a/sysui/desktop/apparmor/program.senddoc
b/sysui/desktop/apparmor/program.senddoc
index d659ec9b98b3..797385f86ca4 100644
--- a/sysui/desktop/apparmor/program.senddoc
+++ b/sysui/desktop/apparmor/program.senddoc
@@ -17,8 +17,8 @@
 profile libreoffice-senddoc INSTDIR-program/senddoc {
   #include 

-  owner /tmp/lu**   rw,#makes files like
luR.tmp/lub.tmp where R is random
-   #Note, usually it's lub or luc, don't
know why.
+  #include 
+
   /{usr/,}bin/shrmix,
   /{usr/,}bin/bash  rmix,
   /{usr/,}bin/dash  rmix,
diff --git a/sysui/desktop/apparmor/program.soffice.bin
b/sysui/desktop/apparmor/program.soffice.bin
index 212eb7c62b15..b8c9f1b2e4b2 100644
--- a/sysui/desktop/apparmor/program.soffice.bin
+++ b/sysui/desktop/apparmor/program.soffice.bin
@@ -92,6 +92,8 @@ profile libreoffice-soffice INSTDIR-program/soffice.bin {
   #include 
   #include 

+  #include 
+
   #List directories for file browser
   / r,
   /**/  r,
@@ -116,7 +119,6 @@ profile libreoffice-soffice
INSTDIR-program/soffice.bin {
   owner @{HOME}/.config/soffice.binrc.lock rwk,
   owner @{HOME}/.cache/fontconfig/**rw,
   owner @{HOME}/.config/gtk-???/bookmarks r,  #Make bookmarks work
-  owner /tmp/psp[0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9]* rw,
#/tmp/psp1534203998 (printing to file)

   owner /{,var/}run/user/*/dconf/user   rw,
   owner @{HOME}/.config/dconf/user  r,
diff --git a/sysui/desktop/apparmor/program.xpdfimport
b/sysui/desktop/apparmor/program.xpdfimport
index efe10dce020d..f8bfbfe8fa49 100644
--- a/sysui/desktop/apparmor/program.xpdfimport
+++ b/sysui/desktop/apparmor/program.xpdfimport
@@ -17,9 +17,8 @@
 profile libreoffice-xpdfimport INSTDIR-program/xpdfimport {
   #include 

-  owner /tmp/*  r, #Seems to need to read file created
with pattern /tmp/RR
-  owner /tmp/lu**   rw,#makes files like
luR.tmp/lub.tmp where R is random
-   #Note, usually it's lub or luc,
don't know why.
+  #include 
+
   /usr/share/poppler/** r,
   /usr/share/libreoffice/share/config/* r,
   owner
@{HOME}/.config/libreoffice{,dev}/?/user/uno_packages/cache/log.txt rw,

(user-tmp allows /tmp/**)

Regards,

Rene

Bug#962903: libreoffice: Fails to open any PDF ("This PDF file is encrypted and can't be opened.")

[Rene Engelhard]

tag 962903 - moreinfo

tag 962903 - unreproducible

retitle 962903 Fails to open any PDF ("This PDF file is encrypted and
can't be opened.") if TMPDIR is not /tmp (apparmor DENIED)

severity 962903 minor

tag 962903 + wontfix

thanks


Am 20.06.20 um 14:11 schrieb Rene Engelhard:
> 2575  19:27:45.464196 openat(AT_FDCWD, "/tmp/test-tmp-ametzler/Qqf3SE", 
> O_RDONLY) = -1 EACCES (Permission denied)
> I wonder about that /tmp/test-tmp-ametzler.
>
>
> The apparmor rules might just allow /tmp/*, not /tmp/something/*.

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

  owner /tmp/*  r, #Seems to need to read file created
with pattern /tmp/RR
  owner /tmp/lu**   rw,    #makes files like
luR.tmp/lub.tmp where R is random
   #Note, usually it's lub or luc, don't
know why.
[...]

> Ah, yes:
>
> Indeed, if I set TMPDIR=/tmp/test I get that
>
> "This PDF file is encrypted and can't be opened".
>
>
> dmesg shows e.g.:
>
> "[  692.0171072] audit: type=1400 audit(159265461.660:88): apparmor="DENIED" 
> opereation="open" profile="libreoffice-xpdfimport" name="/tmp/test/4DyliY" 
> pid=2661 comm="xpdfimport" requested_mask="r" denied_masj="r" fsuid=1000 
> ouid=1000"
>
> And indeed, if I set that profile to complain only it works.

Based on that and the last sentence changing the status and marking this
as wontfix.#

Regards,

Rene

Bug#962903: libreoffice: Fails to open any PDF ("This PDF file is encrypted and can't be opened.")

[Rene Engelhard]

tag 962903 + moreinfo

tag 962903 + unreproducible

thanks

Am 15.06.20 um 19:49 schrieb Andreas Metzler:
> trying to open any PDF file in libreoffices yields the generic
> PDF error page "This PDF file is encrypted and can't be opened.")

Fresh testing VM.


Plain Text doc just containing "Test".


Exported to PDF.


Opening just works. Both in LO and by command line.


Did you do any special config? Something apparmor-related? Some specific
TMPDIR or so?


Because:

> 2575  19:27:45.464196 openat(AT_FDCWD, "/tmp/test-tmp-ametzler/Qqf3SE", 
> O_RDONLY) = -1 EACCES (Permission denied)

I wonder about that /tmp/test-tmp-ametzler.


The apparmor rules might just allow /tmp/*, not /tmp/something/*.


Ah, yes:

Indeed, if I set TMPDIR=/tmp/test I get that

"This PDF file is encrypted and can't be opened".


dmesg shows e.g.:

"[  692.0171072] audit: type=1400 audit(159265461.660:88): apparmor="DENIED" 
opereation="open" profile="libreoffice-xpdfimport" name="/tmp/test/4DyliY" 
pid=2661 comm="xpdfimport" requested_mask="r" denied_masj="r" fsuid=1000 
ouid=1000"

And indeed, if I set that profile to complain only it works.

If *you* change stuff *you* have the responsibility to change stuff so that it 
works with it. This is not a bug here.

Regards,


Rene

Bug#963109: libreoffice: Please drop clang from build-dependencies for alpha and ia64

[Rene Engelhard]

Hi,

Am 19.06.20 um 19:19 schrieb John Paul Adrian Glaubitz:
> On 6/19/20 7:12 PM, Rene Engelhard wrote:
>> Sorry, I don't believe I don't need to fix stuff here myself. ia64 and
>> m68k even didn't yet do a ICU rebuild or at least make stuff being
>> rebuildable.
>>
>>> Would it be okay if I send a pull request to make the necessary changes?
>>
>> I am perfectly able to implement what you want. But whatever.
>>
>> You can send any pull request.
>>
>> That doesn't mean I'll merge it.
> 
> I'll ask the CTTE then.

lol.

> No idea why you have to turn such a simple request into
> such a drama.

*You* turn it in a drama.

I asked for a very simple and modest change and your only answer
> is to turn this into such a long pointless discussion basically telling me I
> shouldn't be doing what I'm doing.

*You* started the debate. I (implicitely, even before, by the comment in
rules and in a message explicity) said I will stay with upstream here,
you continued and trolled about debian/patches when I did so.

Some times you just need to accept maintainers' decisions and not waste
their times with this (indeed) useless discussion.

Regards,

Rene

Bug#963109: libreoffice: Please drop clang from build-dependencies for alpha and ia64

[Rene Engelhard]

Am 19.06.20 um 17:46 schrieb John Paul Adrian Glaubitz:
> On 6/19/20 1:08 PM, r...@rene-engelhard.de wrote:
>> Am 19. Juni 2020 12:52:40 MESZ schrieb John Paul Adrian Glaubitz 
>> :
>>> So nothing that keeps us from using GCC in cases where clang is not
>>> available.
>>
>> Correct. Except staying as close as possible with upstream.
> 
> While at the same time, the source contains 20+ patches:
> 
>> https://salsa.debian.org/libreoffice-team/libreoffice/libreoffice/-/tree/debian-experimental-7.0/patches
> 
> I wouldn't consider that "close to upstream".

*Shrugs*

That shows you haven't even cared to actually have looked at the patch
names but just counting. That is not sensible and just a pure trolling
attempt.

Some patches are needed for proper packaging.

Some patches are requires by policy.

Some patches fix bugs.

Some patches fix FTBFSes.

Some patches are simply minor.

Where a difference to upstream is not actually needed, why do one?

 and disabled on any other architecture. It's not really rocket scien
>>
>> Trust me, I know. I do this for all kind of stuff in rules (e.g. for skia 
>> itself, see below)
> 
> This isn't a technical argument though.

*You* said it's not rocket science and implied I wouldn't be able to do so.

>>> It's also not a given that clang generates faster code on _any_ given
>>> architecture,
>>> it might be true for x86_64, but not necessarily for armhf or s390x.
>>
>> s390x doesn't matter here at all as it is be and skia doesn't support be at 
>> all. Thus we get --disable-skia and thus no clang usage.
>>
>> But generally you're right, but I am trying to stay as close upstream as 
>> possible here.
> 
> Again, this isn't a compelling technical argument. There is no additional 
> workload
> involved if you allow building LO with GCC on non-clang architectures and it 
> also
> does not cause harm any of the release architectures. You are not required to 
> fix
> any code that doesn't build on a non-release architecture, that's what we 
> porters
> are for.
[...]
> I have honestly no clue why you would deny porters to build
LibreOffice on non-release
> architectures given these circumstances.

It is. That line needs to be maintained.

Ah, right, so you fix the stuff?

- alpha broken for ages
- hppa broken for ages
- sparc64 BD-Unistallable for ages due to KDE
- kfreebsd-* BD-Uninstallable for ages

See

https://buildd.debian.org/status/package.php?p=libreoffice

(sid).

Sorry, I don't believe I don't need to fix stuff here myself. ia64 and
m68k even didn't yet do a ICU rebuild or at least make stuff being
rebuildable.

You mean on alpha where you even were not able to keep it building for a
long time? Don't blame your non-action here.

Sorry, I don't believe I don't need to fix stuff here myself. ia64 and
m68k even didn't yet do a ICU rebuild or at least make stuff being
rebuildable.

> Would it be okay if I send a pull request to make the necessary changes?

I am perfectly able to implement what you want. But whatever.

You can send any pull request.

That doesn't mean I'll merge it.

Regards,

Rene

Bug#962582: libreoffice: Menu "Tools / Options..." doesn't open; the program freezes

[Rene Engelhard]

Hi,

Am 10.06.20 um 17:20 schrieb Teemu Likonen:
> Rene Engelhard [2020-06-10T17:01:28+02] wrote:
>
>> Am 10.06.20 um 16:50 schrieb Teemu Likonen:
>>> there too and with the same strace output. Both computers have Debian


Impossible. The strace iutout clearly says _nvidia. So it simply cannot

be the same.

>>> 10, KDE Plasma desktop and Libreoffice installed with metapackage
>>> "libreoffice".
>> And both the prioprietary nvidia driver?
> No. The other has some Intel card. It uses a driver which Xorg calls
> "intel" (package xserver-xorg-video-intel).

I have an intel card, too. Just works.


xserver-xorg-video-intel is installed, too, but ttbomk it is

only used if you explicitely have it in Xorg.conf. No Xorg.conf should
suffice

and then it uses modesetting and it just works.

> It seems to me that this is a regression in Libreoffice because before
> it worked several years with the same Nvidia and Intel graphic cards.

maybe, I would call LibreOffice even attempting to do stuff with OpenGL

a bug and regression per se. That train left long ago, though.


Regards,


Rene

Bug#962582: libreoffice: Menu "Tools / Options..." doesn't open; the program freezes

[Rene Engelhard]

Hi,

Am 10.06.20 um 16:50 schrieb Teemu Likonen:

> Rene Engelhard [2020-06-10T14:31:54+02] wrote:
>
>> What does strace'ing soffice.bin say? (You'll want to use -ff or
>> something like that)
> I ran this:
>
> strace -o dump -ff /usr/lib/libreoffice/program/soffice.bin

openat(AT_FDCWD, "/usr/lib/x86_64-linux-gnu/libGLX_nvidia.so.0",
O_RDONLY|O_CLOEXEC) = 5

rene@frodo:~$ apt-file search libGLX_nvidia.so.0
libglx-nvidia-legacy-390xx0:
/usr/lib/x86_64-linux-gnu/nvidia/legacy-390xx/libGLX_nvidia.so.0
libglx-nvidia0: /usr/lib/x86_64-linux-gnu/nvidia/current/libGLX_nvidia.so.0
rene@frodo:~$ apt-cache show libglx-nvidia0
Package: libglx-nvidia0
Source: nvidia-graphics-drivers
Version: 418.113-1
Installed-Size: 1562
Maintainer: Debian NVIDIA Maintainers

Architecture: amd64
Provides: libglx-vendor
Depends: nvidia-alternative (= 418.113-1), libglx0 |
libglx0-glvnd-nvidia, libnvidia-glcore (= 418.113-1), libc6 (>= 2.2.5),
libx11-6, libxext6
Description-en: NVIDIA binary GLX library
 GLX ("OpenGL Extension to the X Window System") provides an interface
between
 OpenGL and the X Window System as well as extensions to OpenGL itself.
 .
 See the description of the nvidia-driver package
 or /usr/share/doc/libgl1-nvidia-glx/README.txt.gz
 for a complete list of supported GPUs and PCI IDs.
 .
 This package contains the driver specific binary GLX implementation by
NVIDIA
 that is accessed via GLVND.
Description-md5: ce379c987bbb78e30edc487761a62221
Multi-Arch: same
Homepage: https://www.nvidia.com
Tag: role::shared-lib
Section: non-free/libs
Priority: optional
Filename:
pool/non-free/n/nvidia-graphics-drivers/libglx-nvidia0_418.113-1_amd64.deb
Size: 456116
MD5sum: 80a82645b5288dd659d02d548ef2c135
SHA256: 5d48a6a74df0e89f2ea77416fa128599ff9cc76b5947913f87135ec6f9f9ac6a

As I gussed.


What does happen on a sane system without the proprietary nvidia
driver?I tried all these things with another computer and Libreoffice
freezes

> there too and with the same strace output. Both computers have Debian
> 10, KDE Plasma desktop and Libreoffice installed with metapackage
> "libreoffice".

And both the prioprietary nvidia driver?


Regards,


Rene

Bug#962582: libreoffice: Menu "Tools / Options..." doesn't open; the program freezes

[Rene Engelhard]

tag 962582 + moreinfo

tag 962582 + unreproducible

thanks


Hi,

Am 10.06.20 um 10:42 schrieb Teemu Likonen:
> Libreoffice freezes when opening menu "Tools / Options...". To
> reproduce:
>
>  1. Open a terminal program and a shell.
>  2. Start Libreoffice from the shell:
>
>     loffice --safe-mode
>
>  3. Choose "Continue in Safe Mode".
>  4. Select menu "Tools / Options..."
>  5. Nothing happens except that the program hangs and doesn't react to
>     anything.
>
Just works here. (In normal mode). But I do have a sane system...

What does strace'ing soffice.bin say? (You'll want to use -ff or
something like that)

> I have tried to remove all the Libreoffice packages and purge their
> configuration files (aptitude purge '~c') and then reinstall (apt
> install libreoffice). Does not help.
>
Which doesn't remove the user config.

It can't be the user profile, though if it also happens in safe mode and
you continued with "safe mode"...

> Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
> TAINT_UNSIGNED_MODULE

Oh my...

Regards,


Rene

Bug#961473: libreoffice-kde5: The libreoffice templates in /usr/share/templates are set to Letter page size

[Rene Engelhard]

Hi,

On Mon, May 25, 2020 at 04:36:43PM +0200, Rene Engelhard wrote:
> These files are contained *in the package* (libreoffice-common, even
> language-independent, and you can*t just have multiple versions there.)
> and just installs from upstream:

Sorry, libreoffice-kde5/libreoffice-plasma obviously, but still language
or country-independent.

Regards,

Rene

Bug#961473: libreoffice-kde5: The libreoffice templates in /usr/share/templates are set to Letter page size

[Rene Engelhard]

reassign 961473 libreoffice-kde5,libreoffice-plasma
severity 961473 minor
tag 961473 + upstream
thanks

Hi,

On Sun, May 24, 2020 at 11:43:31PM +0200, Steve Russell wrote:
> Package: libreoffice-kde5
> Version: 1:6.1.5-3+deb10u6

Even if it was a bug, we for sure won't change the default in a stable
release (and all this stuff moved to libreoffice-plasma in newer
releases anyway.)

> When I create a new LibreOffice Writer document using the Create New function 
> in Dolphin, the
> new document has the page size set to Letter. When I attempt to print this 
> document it fails
> because my printer does not have Letter size paper.

And you can't just set it to A4? This is a *template*, not necessarily
something you can just use? That's the sense of a template, to edit it.

And I'd argue it is minor, and not normal.

> I would expect that the installer should detect whether my localization 
> settings are using Letter
> or A4 and install the appropriate template for this paper size.

There is no installer. (Well, the installer isn't involved here.)

These files are contained *in the package* (libreoffice-common, even
language-independent, and you can*t just have multiple versions there.)
and just installs from upstream:

# install files for "create new" ...
mkdir -p $(PKGDIR)-plasma/usr/share/templates/.source
for i in $(SOURCE_TREE)/extras/source/shellnew/*; do \
cp $$i $(PKGDIR)-plasma/usr/share/templates/.source/`basename 
$$i`; \
done


Hovever you do it so you do it wrong, although I agree with you that A4 would
be a far more sensible default...

(The other alternative would be to remove that Create New... support,
people should just use File->New in LibreOffice, imho)

Regards,

Rene

Bug#959399: libreoffice-common: Using libreoffice results in many AppArmor "ALLOWED" log messages in kernel syslog

[Rene Engelhard]

On Sat, May 09, 2020 at 05:16:04PM -0500, Evan Harris wrote:
> > No, $HOME isn't. $HOME in your case is "/raid/home/user/.
> 
> Actually it's not.  In the particular example I gave logs for, $HOME is
> /home/user.  It just happens that /home is a symlink to /raid/home.

Aha...

> > > How should the configuration be changed for multiple home directories 
> > > being
> > > stored and mounted in multiple locations?
> > 
> > Erm, what?
> > 
> > I mentioned
> > 
> > @{libo_user_dirs} = @{HOME} /mnt /media
> 
> I don't know where that is configured.  Where would I find that?

This is cut'n'paste the libreoffice (well
/usr/lib/libreoffice/program/soffice.bin) apparmor profile.

> > Wouldn't be surprised if @{HOME} (documented as "all homedirs") actually
> > means /home/** and thus wouldn't allow /raid/home/**.
> > 
> > I'd first try adding /raid/home there, obviously?
> 
> Where is "there"?

Of course in the apparmor profile.

(/etc/apparmor.d/usr.lib.libreoffice.program.soffice.bin)

BTW: This is not a apparmor or configuration support, this is for
tracking bugs ;-)

Regards,

Rene

Bug#959399: libreoffice-common: Using libreoffice results in many AppArmor "ALLOWED" log messages in kernel syslog

[Rene Engelhard]

Hi,

On Sat, May 09, 2020 at 03:32:48PM -0500, Evan Harris wrote:
> I guess I don't understand what needs to be changed.  $HOME is /home, which
> is where the local users homes are.  There are additional mount points

No, $HOME isn't. $HOME in your case is "/raid/home/user/.

> (/raid, and one other) that hold additional network mounts of remotely store
> users' home directories.

But you run as a remote user?

name="/raid/home/user/.config/libreoffice/4/user/GpDXp7

suggests so.

> How should the configuration be changed for multiple home directories being
> stored and mounted in multiple locations?

Erm, what?

I mentioned

@{libo_user_dirs} = @{HOME} /mnt /media

Wouldn't be surprised if @{HOME} (documented as "all homedirs") actually
means /home/** and thus wouldn't allow /raid/home/**.

I'd first try adding /raid/home there, obviously?

Regards,

Rene

Re: libreoffice & sane-backends

[Rene Engelhard]

Hi,

On Mon, May 04, 2020 at 07:43:06PM +0200, Jörg Frings-Fürst wrote:
> please can someone test the build of libreoffice with sane-
> backends from experimental? My build system runs always out of disk
> space.

Hrmpf. (Iit doesn't really need much disc space
given nowadays' disk sizes.)

Anyways:

https://salsa.debian.org/libreoffice-team/libreoffice/libreoffice/-/commit/a11f5b7381097ea0ae9a3e03db909f4075628935

(2 years ago, when you last attempted the rename)

"Obviously" LO doesn't link against libsane but dlopen()s it.

> Many Thanks.

But yes, just builds.

Regards,

Rene

Bug#959399: libreoffice-common: Using libreoffice results in many AppArmor "ALLOWED" log messages in kernel syslog

[Rene Engelhard]

Hi again.

On Sat, May 02, 2020 at 03:56:26AM +0200, Rene Engelhard wrote:
> > A small sampling of messages (obfuscated):
> > 
> > May  1 17:19:49 host kernel: [ 9201.656675] audit: type=1400 
> > audit(1588371589.713:822): apparmor="ALLOWED" operation="mknod" 
> > profile="libreoffice-soffice" 
> > name="/raid/home/user/.config/libreoffice/4/user/GpDXp7" pid=16453 
> > comm="configmgrWriter" requested_mask="c" denied_mask="c" fsuid=1000 
> > ouid=1000
> 
> why /raid as extra mountpoint and not /home directly or / directly or if
> that's not intended some bind mounts to have /home on a "known"
> location? So that stuff like this doesn't knowingly break?
> Or is that the case?

And what is your @HOME set for in apparmor sense?

  owner @{HOME}/.config/libreoffice{,dev}/** rwk,

is in the profile, which allows the owner of the config dir in @{HOME}
access.

So I just bet that setting needs to be globally adapted
for apparmor?
(Or use standard paths.)

Regards,

Rene

Bug#959399: libreoffice-common: Using libreoffice results in many AppArmor "ALLOWED" log messages in kernel syslog

[Rene Engelhard]

retitle 959399 libreoffice-common: many AppArmor "ALLOWED" log messages
if using "non-standard" $HOME
severity 959399 minor
tag 959399 + wontfix
thanks

On Fri, May 01, 2020 at 06:00:46PM -0500, E Harris wrote:
> Using LibreOffice results in many AppArmor audit log messages marked as 
> "ALLOWED".
> These messages repeat many times during normal use of the app, resulting in 
> quite a bit of log spam.
> 
> Perhaps this is the result of the user's home directory being mounted in an 
> alternate location?

Yes, and to be honest, if you change that dir you need to change all
profiles referencing $HOME to allow it.

Here you can be just glad it works because the profile is in complain
mode, if it wasn't this wouldn't work at all...

One simply cannot allow any path as this would simply defeat the
purpose.

> 
> A small sampling of messages (obfuscated):
> 
> May  1 17:19:49 host kernel: [ 9201.656675] audit: type=1400 
> audit(1588371589.713:822): apparmor="ALLOWED" operation="mknod" 
> profile="libreoffice-soffice" 
> name="/raid/home/user/.config/libreoffice/4/user/GpDXp7" pid=16453 
> comm="configmgrWriter" requested_mask="c" denied_mask="c" fsuid=1000 ouid=1000

why /raid as extra mountpoint and not /home directly or / directly or if
that's not intended some bind mounts to have /home on a "known"
location? So that stuff like this doesn't knowingly break?
Or is that the case?

I am honestly not sure whether there's something to do there at all -
except for the admin of the system to adapt the profile to the setuo of
the system.

Regards,

Rene

Bug#957475: libreoffice: ftbfs with GCC-10

[Rene Engelhard]

# not sure. close if appropriate.
clone 957475 -1
reassign -1 src:boost1.71
notforwarded -1
block 957475 by -1
retitle 957475 boost1.71 needs fixes for gcc 10
thanks

Hi,

On Fri, Apr 17, 2020 at 04:32:33PM +0200, Rene Engelhard wrote:
> This complains about stuff inside a boost header i(which is header-only
> here)...
> 
> And indeed, building with boost 1.71 does NOT give the error. So Debians

But it gives an other :(:
https://www.rene-engelhard.de/~rene/libreoffice/boost-gcc10.log
Also reassigning a clone to boost 1.71.

But thankfully upstream fixed it in master:
17:05 <@sberg> _rene_, see 55c724b93dfd4c9a1afb10d60fbc2d7a9a66cf61, or 
alternatively another case where dropping support for -std=c++20/-std=c++2a 
from 
   configure.ac should help
17:05 < IZBot> core - replace boost::bimap in sdext pdfimport - 
https://git.libreoffice.org/core/commit/55c724b93dfd4c9a1afb10d60fbc2d7a9a66cf61
17:05 <@thorsten> cloph_away samuel_m timar: no strong take how to fix that on 
the builder, fallback to from-source poco again?
17:06 <@sberg> I'd pondered hiding that -std=c++20/2a behind some 
--with-latest-c++; should probably introduce that
17:05 <@sberg> _rene_, see 55c724b93dfd4c9a1afb10d60fbc2d7a9a66cf61, or 
alternatively another case where dropping support for -std=c++20/-std=c++2a 
from 
   configure.ac should help
17:05 < IZBot> core - replace boost::bimap in sdext pdfimport - 
https://git.libreoffice.org/core/commit/55c724b93dfd4c9a1afb10d60fbc2d7a9a66cf61
17:05 <@thorsten> cloph_away samuel_m timar: no strong take how to fix that on 
the builder, fallback to from-source poco again?
17:06 <@sberg> I'd pondered hiding that -std=c++20/2a behind some 
--with-latest-c++; should probably introduce that

-> 
https://cgit.freedesktop.org/libreoffice/core/commit/?id=55c724b93dfd4c9a1afb10d60fbc2d7a9a66cf61

Will backport.

Regards,

Rene

Bug#957475: libreoffice: ftbfs with GCC-10

[Rene Engelhard]

clone 957475 -1
reassign -1 src:boost1.67
notforwarded -1
block 957475 by -1
retitle 957475 boost1.67 needs fixes for gcc 10
thanks

Hi,

On Fri, Apr 17, 2020 at 11:04:54AM +, Matthias Klose wrote:
> [build CXX] vcl/source/window/menuitemlist.cxx
> In file included from /<>/vcl/source/window/layout.cxx:21:
> /usr/include/boost/multi_array.hpp: In instantiation of ‘void 
> boost::multi_array::allocate_space() [with T = 
> GridEntry; long unsigned int NumDims = 2; Allocator = 
> std::allocator]’:
> /usr/include/boost/multi_array.hpp:148:5:   required from 
> ‘boost::multi_array::multi_array() [with T = 
> GridEntry; long unsigned int NumDims = 2; Allocator = 
> std::allocator]’
> /<>/vcl/source/window/layout.cxx:819:16:   required from here
> /usr/include/boost/multi_array.hpp:478:39: error: no type named 
> ‘const_pointer’ in ‘class std::allocator’
>   478 | typename Allocator::const_pointer no_hint=0;
>   |   ^~~
> /usr/include/boost/multi_array.hpp:478:39: error: no type named 
> ‘const_pointer’ in ‘class std::allocator’
> /usr/include/boost/multi_array.hpp: In instantiation of ‘void 
> boost::multi_array::deallocate_space() [with T = 
> GridEntry; long unsigned int NumDims = 2; Allocator = 
> std::allocator]’:
> /usr/include/boost/multi_array.hpp:473:5:   required from 
> ‘boost::multi_array::~multi_array() [with T = 
> GridEntry; long unsigned int NumDims = 2; Allocator = 
> std::allocator]’
> /<>/vcl/source/window/layout.cxx:819:16:   required from here
> /usr/include/boost/multi_array.hpp:488:20: error: ‘class 
> std::allocator’ has no member named ‘destroy’
>   488 | allocator_.destroy(i);
>   | ~~~^~~

This complains about stuff inside a boost header i(which is header-only
here)...

And indeed, building with boost 1.71 does NOT give the error. So Debians
old default boost strikes again. Either boost1.67 needs to be fixed or
the default changed before gcc 10.

Regards,

Rene

Bug#957475: libreoffice: ftbfs with GCC-10

[Rene Engelhard]

forwarded 957475 Stephan Bergmann 
thanks

On Fri, Apr 17, 2020 at 11:04:54AM +, Matthias Klose wrote:
> In file included from /<>/include/rtl/ustring.hxx:37,
>   
>   
>  from /<>/include/comphelper/lok.hxx:14, 
>   
>   
>  from /<>/vcl/source/window/builder.cxx:16:  
>   
>   
> In constructor ‘rtl::OString::OString(rtl::OStringConcat&&) [with T1 
> = rtl::OString; T2 = const char [11]]’,   
>
> inlined from ‘VclPtr VclBuilder::makeObject(vcl::Window*, 
> const rtl::OString&, const rtl::OString&, VclBuilder::stringmap&)’ at 
>  
> +/<>/vcl/source/window/builder.cxx:2122:54:  
>   
>   
> /<>/include/rtl/string.hxx:280:18: warning: writing 1 byte into 
> a region of size 0 [-Wstringop-overflow=] 
>
>  280 | *end = '\0';   
>   
>  
>  | ~^~
>   
>  

Forwarded upstream (per IRC)

Upstream says:

14:14 <@sberg> _rene_, and note 

Which says:

"Silence bogus -Wstringop-overflow with GCC trunk towards GCC 10

...see  "Unhelpful
-Wstringop-overflow warning"
"

(there's some more stuff like this, though, but I don't build with
-Werror anyway, so just noting)

Regards,

Rene

Bug#956586: Problems upgrading LibreOffice from "1:6.1.5-3+deb10u5" to "1:6.4.2-3"

[Rene Engelhard]

reassign 956586 src:libreoffice
retitle 956586 buster -> bullseye upgrade deinstalls -gtk2 without installing 
-gtk3
severity 956586 minor
tag 956586 + wonftix
found 956586 1:6.4.0~alpha1-0reprotest1
thanks

[ If you send a bug, please use a non-generic subject ]

Hi,

On Mon, Apr 13, 2020 at 01:34:58PM +0300, Сергей Фёдоров wrote:
> Package: libreoffice
> Version: 1:6.1.5-3+deb10u5

If at all, this would be a bug in the newer version, not the old one :)

> Tags: a11y

Erm? No. Why?

> When upgrading LibreOffice from "1:6.1.5-3+deb10u5" (Debian 10.3 64) to
> "1:6.4.2-3", you are asked to delete libreoffice-gtk2" 1:6.1.5-3+deb10u5",
> but for some reason you do not need to install libreoffice-gtk3. 

And?

> This makes it
> very inconvenient to save a file in LibreOffice, even though "1:6.4.2-3"
> only works with Gtk3.

No, you just install libreoffice-gtk3.

And I believe it's the admins' job to look what a upgrade will do, see
that gtk2 will be gone and maybe install -gtk3. I.e. yours..

Even if one wanted to "fix" this - how would you do this?

Gtk2 support is gone. Even upstream.

Add a transitional package -gtk2 with a hard depend on -gtk3? Don't
think we should do that? It's not as if it was renamed or moved betwen
packages, it's simply gone.

Hard depends on gtk3? Don't think KDE people or people not using a
Gtk-using Desktop will like this.

If you installed via a task you'll get the task recommending -gtk3 now
anyway and get the new dependency - the tasks already got updated ttbomk.

Regards,

Rene

Re: Print dialog too high - need to test an upstream fix

[Rene Engelhard]

On Sun, Apr 12, 2020 at 06:55:18PM +0200, Rene Engelhard wrote:
> > Would you please can make a compilation of this nigtly build somewere
> > (experimental?) so I can confirm upstream that the problem is fixed#

Looks like it is, there is now an expander. The dialog itself will be
bigger than the screen when expanded, but that easily can be unexpanded.

So it moved from a problem to just a minor nuisance :)

Regards,
 
Rene
> 

Re: Print dialog too high - need to test an upstream fix

[Rene Engelhard]

Hi,

On Sun, Apr 12, 2020 at 06:55:18PM +0200, Rene Engelhard wrote:
> But will do and upload to
> https://people.debian.org/~rene/libreoffice/6.4/snapshots/.
> (en-US only and amd64 only of course)

Done.

Regards,
 
Rene

Re: Print dialog too high - need to test an upstream fix

[Rene Engelhard]

[ Mail ended up somewhere in nirvana, not here, not in Spam but in the 
mailing list archives... ]


Hi,

> Would you please can make a compilation of this nigtly build somewere
> (experimental?) so I can confirm upstream that the problem is fixed#

No, I am not uploading random snapshots to experimental. (Besides that,
experimental is currently carrying 6.4.3 rc2). Yes, 6.4.4 rc1 will come 
to experimental when it's there 
(https://wiki.documentfoundation.org/ReleasePlan/6.4#6.4.4_release)


But will do and upload to 
https://people.debian.org/~rene/libreoffice/6.4/snapshots/.

(en-US only and amd64 only of course)

> or, if that is not possible, can you give me instructions on how to
build a package from that source?

This is documented in the source package already and if you know about 
how to build a debian package should simply be possible if you pick the 
correct git branch..


You use a development release...

Regards,

Rene

Bug#956450: libreoffice-common: Upgrade fail because of Application.xba file conflict with libreoffice-base

[Rene Engelhard]

Hi,

On Sat, Apr 11, 2020 at 03:11:46PM +0200, Petter Reinholdtsen wrote:
> [Rene Engelhard]
> > I think if it was a generic problem this would have been reported
> > LOOONG go:
> 
> No idea if it is a generic problem, but we ran into it on two different
> machines, one yesterday and one today, when we decided to migrate the
> two machines to bullseye, so it is not a very rare problem. :)

But you are the second one only (and the first one in Debian at all) to
report it since November...

Regards,

Rene

Bug#956450: libreoffice-common: Upgrade fail because of Application.xba file conflict with libreoffice-base

[Rene Engelhard]

found 956450 1:6.4.0~beta1-2
tag 956450 + pending
thanks

Hi,

On Sat, Apr 11, 2020 at 02:09:47PM +0200, Petter Reinholdtsen wrote:
> Upgrading a KDE desktop from from buster to bullseye using 'apt
> dist-upgrade' fail because apt aborts halfway in the process when trying
> to unpack libreoffice-common version 1:6.4.2-3 over version
> 1:6.1.5-3+deb1@u5, because the new package contain the file
> /usr/lib/libreoffice/share/basic/Access2Base/Application.xba which is
> also in the package libreoffice-base 1:6.1.5-3+deb1@u5.

Hrmpf. I tried various buster upgrades when I moved the files and it simply
worked... (Even in a VM with GNOME, KDE, whatever installed. But maybe
that changes order so that it works.).

Ubuntu reported this some days ago, too, but as said never saw it myself.

I think if it was a generic problem this would have been reported LOOONG
go:

libreoffice (1:6.4.0~beta1-2) experimental; urgency=medium

  * debian/control*in, debian/*.lintian-overrides: fix some minor lintian
stuff after the library splitout
  * debian/control.test-packages.in, debian/rules: move smoketest.jar into
libreoffice-smoketest-data
  * debian/control.in, debian/rules, debian/libreoffice-base.p*.in:
simplify and revert diversion of AccessBase basic stuff.
  * debian/libreoffice-common.docs, debian/libreoffice-common.doc-base,
debian/patches/add-access2base-doc.diff: install
www.access2base.com/access2base.html into libreoffice-common as doc

 -- Rene Engelhard   Sun, 17 Nov 2019 13:34:51 +0100

> Missing breaks/replaces?

Already added:

https://salsa.debian.org/libreoffice-team/libreoffice/libreoffice/-/commit/3c9fe519addf03f31ab28e689ef35bfb903c9868

Regards,

Rene

Re: wrong language

[Rene Engelhard]

On Fri, Apr 10, 2020 at 06:06:42PM +0200, Yngve Spjeld-Landro wrote:
> There are two official and equal variants of Norwegian, Nynorsk and Bokmål.
> Claiming that the Bokmål variant is Norwegian is wrong. Please update the
> description of the package to
> 
> libreoffice-l10n-nb (1:6.4.2-3~bpo10+1)
> office productivity suite -- Norwegian Bokmål language package

Fair point. So norwegian_bokmal. (see below)

> The description for the Norwegian Nynorsk package could also be slightly
> changed from
> 
> libreoffice-l10n-nn (1:6.4.2-3~bpo10+1)
> office productivity suite -- Norwegian_nynorsk language package
> 
> to
> 
> libreoffice-l10n-nn (1:6.4.2-3~bpo10+1)
> office productivity suite -- Norwegian Nynorsk language package

https://cgit.freedesktop.org/libreoffice/core/tree/bin/lo-xlate-lang#n113

"norwegian" is not the only one affected (also portuguese, chinese, ...)

Regards,

Rene

Bug#955981: libreoffice-gtk3: Bottom of the LibreOffice Writer print dialog window appears off-screen making it unusable.

[Rene Engelhard]

# mark as found in a ancestor (as in the bz bug)
# otherwise 1:6.4.3~rc3-* from experimental are not marked
# as affected (since 1:6.4.2-3 is branch, see the version tracking...)
found 955981 1:6.3.0-1
tag 955981 + upstream
forwarded 955981 https://bugs.documentfoundation.org/show_bug.cgi?id=127782
thanks

Hi,

On Sun, Apr 05, 2020 at 06:06:18PM +0100, Diogo wrote:
> The bottom of the LibreOffice Writer print dialog window appears off-screen
> making it unusable because the buttons are off-screen. (1366*768 screen
> resolution).

That is https://bugs.documentfoundation.org/show_bug.cgi?id=127782
upstream. Looks like the fix attempted for 6.4.2 didn't work.

Regards,

Rene

Bug#955539: libreoffice: Incomplete upgrade due to libreoffice-math conflict

[Rene Engelhard]

severity 955539 serious
found 955539 1:6.4.2~rc1-1
close 955539 1:6.4.2-3
thanks

On Thu, Apr 02, 2020 at 11:04:43AM +0200, Josep Lladonosa i Capell wrote:
> Source: libreoffice
> Version: partial upgrade to 6.4.2-2~bpo10+1 version due to libreoffice-math 
> 6.3.2-1~bpo10+1 conflict

No, Version: is parsed. It is not a free-form text. It gets parsed to the 
version graph
you see iin the upper right corner...

And in this case, also note https://backports.debian.org/Instructions/
---
Report Bugs
Please report bugs that you found in the packages to the backports
mailing list and NOT to the Debian BTS!
---

Although in this case the bug is not backports-specific and already fixed, so it
doesn't really matter much...

> Conflict was caused by libreoffice-math 6.4.2-2~bpo10+1 that was trying to get
> installed with the same existing package 1:6.3.2-1~bpo10+1x.
[...]
> S'està preparant per a desempaquetar …/libreoffice-
> math_1%3a6.4.2-2~bpo10+1_amd64.deb…
> S'està desempaquetant libreoffice-math (1:6.4.2-2~bpo10+1) sobre
> (1:6.3.2-1~bpo10+1)…
> dpkg: s'ha produït un error en processar l'arxiu
> /var/cache/apt/archives/libreoffice-math_1%3a6.4.2-2~bpo10+1_amd64.deb
> (--unpack):
>  s'està intentant sobreescriure
> «/usr/lib/libreoffice/share/config/soffice.cfg/modules/smath/menubar/menubar.xml»,
> que també està en el paquet libreoffice-common 1:6.3.2-1~bpo10+1
> dpkg-deb: s'ha produït un error: el subprocés «enganxa» ha estat finalitzat 
> pel
> senyal (La canonada s’ha trencat)
> Restoring backup of /usr/share/doc/libreoffice-math ...
> S'han trobat errors en processar:
>  /var/cache/apt/archives/libreoffice-math_1%3a6.4.2-2~bpo10+1_amd64.deb
> E: Sub-process /usr/bin/dpkg returned an error code (1)
> ++

Yeah, known bug. Already fixed in 6.4.2-3 which I cannot backport yet
due to it not being in testing yet.

libreoffice (1:6.4.2-3) unstable; urgency=medium
[...]
- libreoffice-math: Add Breaks/Replaces libreoffice-common
  (<< 1:6.4.2~rc1~)
[...]
 -- Rene Engelhard   Sat, 28 Mar 2020 06:53:24 +0100

Regards,

Rene

Bug#955272: libreoffice: unable to sign existing PDFs: foo.tmp doesn't exist

[Rene Engelhard]

tag 955272 + upstream
forwarded 955272 https://bugs.documentfoundation.org/show_bug.cgi?id=130354
thanks

On Sat, Mar 28, 2020 at 10:29:01PM -0400, John Scott wrote:
>  1. Open LibreOffice and navigate to File -> Digital Signatures -> Sign 
> Existing PDF
>  2. Choose a PDF, and in the Writer window that opens choose 'Sign Document'
>  3. A message appears saying something like
>   '/home/john/Documents/lu97947ceyaav.tmp does not exist.'
> and if one clicks OK, the dialog appears once more.

Sounds like https://bugs.documentfoundation.org/show_bug.cgi?id=130354

Regards,

Rene

Bug#955271: libreoffice-common: AppArmor profile blocks gpg's tofu.db, causes hang opening Options

[Rene Engelhard]

user pkg-apparmor-t...@lists.alioth.debian.org
usertag - buggy-profile
thanks

Hi,

On Sat, Mar 28, 2020 at 10:06:43PM -0400, John Scott wrote:
> User: pkg-apparmor-t...@lists.alioth.debian.org
> Usertags: buggy-profile

Sorry, no.
Just because we didn't have the TOFU trust model in mind the
profile is "buggy"?

It is *your* decision to set it. So *you* have to deal with fallout.
One can't just support any possible configuration.

One of which is to file this report, the other one is to use the
"default" trust model?

> This is observed in 1:6.4.2-2 also. It's probably dependent on me using the
> tofu trust model,

Probably, otherwise I've never seen gnupg wanting tofu.db

> and I'm not sure whether it would affect someone not having
> this setting.

It doesn't. At least when I tested this last when writing the profile.

> - -- Configuration Files:
> /etc/apparmor.d/usr.lib.libreoffice.program.soffice.bin changed [not included]
>  * I had set it to complain mode

It is in complain mode per default anyway.

Regards

Bug#954849: libreoffice: crash after update

[Rene Engelhard]

Hi,

On Tue, Mar 24, 2020 at 10:08:03PM +0100, Marcin Krawczyk wrote:
> : CommandLine Error: Option 'limited-coverage-experimental' registered more
> than once!
> LLVM ERROR: inconsistency in registered CommandLine options

Thq question still is what involves some CommandLine thingy of LLVM
here.

> Start-Date: 2020-03-23  21:38:19
> Commandline: apt install ./gdm3setup-utils-20140306-1.deb
> Requested-By: marcin (1000)
> Install: gdm3setup-utils:amd64 (20140306-1)
> End-Date: 2020-03-23  21:38:20

Are you installing random package from somewhere?

> > > LLVM ERROR: inconsistency in registered CommandLine options
> > LO does not use LLVM. So what are you using which is and throws this
> > error?
> There is just xterm, but console doesn't matter
> Only libreoffice crashes and I don't know why all rest apps works fine

I was more aiming at some tool using libreoffice, extension,  Or
some library from Debian replaced why whatever you installed from
somewhere

> > > Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
> > > TAINT_UNSIGNED_MODULE
> what that means
> > Oh my..

... or some proprietary X driver or some else proprietary stuff.

Regards,

Rene

Bug#954849: libreoffice: crash after update

[Rene Engelhard]

tag 954849 + moreinfo
tag 954849 + unreproducible
thanks

Hi,

On Tue, Mar 24, 2020 at 02:06:52PM +0100, Marcin Krawczyk wrote:
> * What led up to the situation?
> After night upgrade libreoffice crash when is opened

Which packages did get upgraded?

> * What exactly did you do (or not do) that was effective (or ineffective)?
> Ineffective: reinstalling, trying install older version,

Erm? So you mean you reinstalled LO and tried to install a older LO version
and it still crashed? Why are you filing this against LO then? Shouldn't
it be better debugged to what actually causes the issue?

> * What was the outcome of this action?
> 
> in console I get message:
> : CommandLine Error: Option 'limited-coverage-experimental' registered more
> than once!
> LLVM ERROR: inconsistency in registered CommandLine options

LO does not use LLVM. So what are you using which is and throws this
error?

> Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
> TAINT_UNSIGNED_MODULE

Oh my..

Needless to say: Works in a clean sid chroot (with the state from
yesterday and freshly updated just now.)

Regards,

Rene

Bug#954670: libreoffice-core-nogui segfaults due to missing libuuilo.so on armhf

[Rene Engelhard]

Hi,

On Sun, Mar 22, 2020 at 02:29:00PM +0100, Jochen Sprickerhof wrote:
> # strace -ff loffice --headless --convert-to pdf foo.doc
> 
> [..]
> [pid 14336] openat(AT_FDCWD, "/usr/lib/libreoffice/program/libuuilo.so", 
> O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 ENOENT (No such file or directory)
> [pid 14336] --- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, 
> si_addr=0x6c002e} ---
> 
> Copying in libuuilo.so from libreoffice-core makes it work.

Hmm, ok.

> I wasn't able to reproduce this on amd64.

So I guess we need to relax

# remove lib*uilo.so in --nogui
find debian/libreoffice-*-nogui/$(OODIR)/program/lib*uilo.so -exec rm 
{} \;

which is to greedy ;-)

Regards,

Rene

Bug#954323: libreoffice-common: Update to 1:6.4.2-1 renders libreoffice-writer unusable

[rene . engelhard]

severity 954323 serious
retitle 954323 libreoffice-common 6.4.2 breaks older versions
found 954323 1:6.4.2~rc1-1
thanks

Am 20. März 2020 09:17:51 MEZ schrieb Ara Keary :
>Package: libreoffice-common
>Version: 1:6.4.2-1
>Severity: grave
>Justification: renders package unusable

Sigh.

>. or the document opens, but no menu is available, icons are scattered.

That is expected, all .ui Files moved to the respective packages.

>Note that in the last debian update, many other packages were upgraded
>to
>1:6.4.2-1 .

Which? As at the time of your report the amd64 binaries now containing the UI 
Files were not in the archive proper?

>Versions of packages libreoffice-common depends on:
>ii  libnumbertext-data 1.0.5-3
>ii  libreoffice-style-colibre  1:6.4.2-1
>ii  libreoffice-style-tango1:6.4.2-1

Here we see the arch-indep packages at 6.4.2...

>ii  ure1:6.4.1-1+b1

And as expected the arch-dep packages at 6.4.1.
I would guess libreoffice-writer and -core etc are also at 6.4.1..

>ii  libreoffice-core 1:6.4.1-1+b1

As guessed.

And -core does depend on a 6.4.2 package, but indeed -common misses a Breaks: 
to 6.4.1 packages..

(This could not have happened some time ago because common also had a versioned 
dependency on core but people don't like circular dependencies...)

In any case, upgrade with the amd64 binaries and it should work.

Will add the Breaks: of course..

Regards

Rene

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

Bug#952748: closed by Debian FTP Masters (reply to Alastair McKinstry ) (Bug#952748: fixed in cfgrib 0.9.7.7-2)

[Rene Engelhard]

reopen 952748
thanks

Hi,

On Mon, Mar 16, 2020 at 06:37:03PM +, Brian Potkin wrote:
> > This is an automatic notification regarding your Bug report
> > which was filed against the libreoffice package:
> > 
> > #952748: libreoffice: Printer and queue attributes not available
[...]
> > Date: Mon, 16 Mar 2020 11:04:14 +
> > From: Debian FTP Masters 
> > To: 952748-cl...@bugs.debian.org
> > Subject: Bug#952748: fixed in cfgrib 0.9.7.7-2
> > Reply-To: Alastair McKinstry 
> > 
> > Source: cfgrib
> > Source-Version: 0.9.7.7-2
> > Done: Alastair McKinstry 
[...]
> > Changes:
> >  cfgrib (0.9.7.7-2) unstable; urgency=medium
> >  .
> >* Add python3-cfgrib to test depends. Add simple load test
> >* Add depends on python3-cffi
> >  Closes: #952748
[...]
> This appears to have nothing to do with the issue I raised.

Probably Alastair just typoed the bugnr

Regards,

Rene

Bug#952347: Processed: reassign 952347 to libreoffice-dev, affects 952347

[Rene Engelhard]

Hi,

On Sat, Mar 14, 2020 at 12:36:34PM +0100, Rene Engelhard wrote:
> On Sat, Mar 14, 2020 at 12:20:00PM +0100, Andreas Beckmann wrote:
> > Since you already have a gengal wrapper script, you could check for
> > libreoffice-core being installed and error out with "please install
> > libreoffice-core instead of libreoffice-core-nogui to use this tool"
> > instead of failing with a weird missing symbol.
> 
> Which wouldn't really help here as stuff will still "FTBFS" if they only used
> -core-nogui, but yeah, one can add this nevertheless.

https://salsa.debian.org/libreoffice-team/libreoffice/libreoffice/-/commit/f16f367fcee34e6036053d85e68fc2f53a07732f

Regards,
 
Rene

Bug#952347: Processed: reassign 952347 to libreoffice-dev, affects 952347

[Rene Engelhard]

Hi,

On Sat, Mar 14, 2020 at 12:36:34PM +0100, Rene Engelhard wrote:
> Thinking about this now actually, maybe it suffices to use a
> --disable-gui version of gengal.bin for -dev here... Will try..

Hmm, no, won't work. We don't build the nogui variant everywhere
(double build), so we'd get a problem still on arm* (except arm64),
mips*.

Regards,
 
Rene

Bug#952347: Processed: reassign 952347 to libreoffice-dev, affects 952347

[Rene Engelhard]

On Sat, Mar 14, 2020 at 12:20:00PM +0100, Andreas Beckmann wrote:
> On 14/03/2020 09.51, Rene Engelhard wrote:
> > Maybe split it out to a new libreoffice-dev-gui package or somesuch? (That 
> > would need NEW though,
> > and thus will only be done with the 7.0 packages)? But a tiny package just 
> > for this tool... (that's why
> > it was consumed in the -dev package.)
> I'd go the libreoffice-gui-dev way, it will avoid this kind of confusion

I had planned on -dev-gui. (To match to current -core vs. -core-nogui etc.)

Strictly speaking gengal.bin is not a GUI tool anyway, it seems though
it's just happens to be linked with GUI libs/glx functions.

Thinking about this now actually, maybe it suffices to use a
--disable-gui version of gengal.bin for -dev here... Will try..

But then we still would need it for ui-previewer... Though I am actually
not sure this is used anywhere except for "core" LibreOffice
development

> in the future. Postponing to 7 (or any other reason to go through NEW)
> is fine.

OK, already done for the 7.0 packages:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=952347#29

If the above hack will work, one might be able to revert that :-)

> > Or Recommends: libreoffice-core, though that probably wouldn't be honoured 
> > by sbuild
> Yep, Recommends is not sufficient.
> 
> Since you already have a gengal wrapper script, you could check for
> libreoffice-core being installed and error out with "please install
> libreoffice-core instead of libreoffice-core-nogui to use this tool"
> instead of failing with a weird missing symbol.

Which wouldn't really help here as stuff will still "FTBFS" if they only used
-core-nogui, but yeah, one can add this nevertheless.

Regards,

Rene

Bug#952347: Processed: reassign 952347 to libreoffice-dev, affects 952347

[Rene Engelhard]

retitle 952347 /usr/lib/libreoffice/program/gengal.bin: symbol lookup error: 
/usr/lib/libreoffice/program/gengal.bin: undefined symbol: _Z10getGlxPipev with 
libreoffice-core-nogui installed
clone 952347 -1
reassign -1 src:openclipart
retitle -1 openclipart: please add a explicit build-dependency on
libreoffice-core
thanks

Hi,

On Fri, Mar 13, 2020 at 10:54:11PM +, Debian Bug Tracking System wrote:
> Processing commands for cont...@bugs.debian.org:
> 
> > reassign 952347 libreoffice-dev 1:6.4.1~rc1-2
> Bug #952347 [src:openclipart] openclipart: FTBFS: 
> /usr/lib/libreoffice/program/gengal.bin: symbol lookup error: 
> /usr/lib/libreoffice/program/gengal.bin: undefined symbol: _Z10getGlxPipev
> Bug reassigned from package 'src:openclipart' to 'libreoffice-dev'.
> No longer marked as found in versions openclipart/1:0.18+dfsg-15.
> Ignoring request to alter fixed versions of bug #952347 to the same values 
> previously set
> Bug #952347 [libreoffice-dev] openclipart: FTBFS: 
> /usr/lib/libreoffice/program/gengal.bin: symbol lookup error: 
> /usr/lib/libreoffice/program/gengal.bin: undefined symbol: _Z10getGlxPipev
> Marked as found in versions libreoffice/1:i6.4.1~rc1-2.

Glx is GUI stuff.

Indeed, in the bug the buildlog shows:

[...]
Get:229 http://127.0.0.1:/debian sid/main amd64
libreoffice-core-nogui amd64 1:6.4.1~rc1-2 [29.4 MB]
Get:230 http://127.0.0.1:/debian sid/main amd64
libreoffice-dev-common all 1:6.4.1~rc1-2 [1571 kB]
[...]

And -devs Depends: allow -core-nogui first:

Package: libreoffice-dev
Section: devel
Architecture: alpha amd64 arm64 armel armhf hppa i386 ia64 kfreebsd-amd64 
kfreebsd-i386 m68k mips mipsel mips64 mips64el powerpc powerpcspe ppc64 ppc64el 
s390 s390x sparc sparc64
Depends: libreoffice-core-nogui (= ${binary:Version}) | libreoffice-core (= 
${binary:Version}),
 libreoffice-dev-common (= ${source:Version}),
 ${idlc-cpp-depends},
 ${misc:Depends},
 ${shlibs:Depends}
Recommends: g++, ${java-common-depends}, ${java-runtime-depends}
[...]

With -core installed, it just works:

root@frodo:/# dpkg -l libreoffice-core libreoffice-core-nogui
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name   Version   Architecture Description
+++-==-=--=
ii  libreoffice-core   1:6.4.2~rc2-1 amd64office productivity suite 
-- arch-dependent files
un  libreoffice-core-nogui(no description available)
root@frodo:/# /usr/lib/libreoffice/program/gengal.bin
Utility to generate LibreOffice gallery files

using: gengal --name  --path  [ --destdir  ]
  [ files ... ]

options:
 --name  defines the user visible name of the created or updated 
theme.
 --pathdefines directory where the gallery files are created
or updated.
 --destdir defines a path prefix to be removed from the paths
stored in the gallery files. It is useful to create
RPM packages using the BuildRoot feature.
 --relative-urlsflags that after removing the destdir, the URL 
should be a path relative to the gallery folder in the install
primarily used for internal gallery generation at 
compile time.
theme files.
 files  lists files to be added to the gallery. Absolute paths
are required.
root@frodo:/# apt -t experimental install libreoffice-core-nogui
Reading package lists... Done
Building dependency tree   
Reading state information... Done
Recommended packages:
  libpaper-utils
The following packages will be REMOVED:
  libreoffice libreoffice-calc libreoffice-core
The following NEW packages will be installed:
  libreoffice-core-nogui
0 upgraded, 1 newly installed, 3 to remove and 116 not upgraded.
Need to get 29.4 MB of archives.
After this operation, 38.2 MB disk space will be freed.
Do you want to continue? [Y/n] 
Get:1 http://deb.debian.org/debian experimental/main amd64 
libreoffice-core-nogui amd64 1:6.4.2~rc2-1 [29.4 MB]
Fetched 29.4 MB in 5s (5617 kB/s) 
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = (unset),
LC_ALL = (unset),
LANG = "de_DE.UTF-8"
are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
locale: Cannot set LC_CTYPE to default locale: No such file or directory
locale: Cannot set LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory
debconf: delaying package configuration, since apt-utils is not installed
E: Can not write log (Is /dev/pts mounted?) - posix_openpt (2: No such 

Bug#952748: libreoffice: Printer and queue attributes not available

[Rene Engelhard]

Hi,

On Fri, Feb 28, 2020 at 06:17:21PM +, Brian Potkin wrote:
> On Fri 28 Feb 2020 at 16:29:58 +0100, Rene Engelhard wrote:
> 
> > Keeping the bug explicitely out of the loop.
> 
> I do not understand why.

Because of my first point.

> The subject matter is of legitimate concern.

I didn't say otherwise.

> Rene Engelhard's opinion is that this is not an important bug and the
> severity could be reduced to as low as wishlist.

No, I said 

"It would be good to" is (imho) not a important bug though, but maybe
normal or minor or even wishlist.  

> The essence of the report's content was not addressed.

True. One step at a time. I also didn't say it wouldn't be adressed.
(In any case, this would be upstream who needed to address it in any
case.)

Regards,

Rene

Bug#951149: more info

[Rene Engelhard]

On Sat, Feb 15, 2020 at 06:15:34PM -0800, Peter Eckersley wrote:
> I saw this on a sid system with dpkg 1.19.0.4 installed (piecemeal upgrades).

dpkg (1.19.1) unstable; urgency=medium
[...]
  * Add a new --no-rename option to dpkg-divert. This is the current default
behavior, but it will make it possible to do a default switch in 1.20.x.
[...]

 -- Guillem Jover   Wed, 26 Sep 2018 15:13:22 +0200

Regards,

Rene

Bug#951149: more info

[Rene Engelhard]

Hi,

On Sat, Feb 15, 2020 at 06:15:34PM -0800, Peter Eckersley wrote:
> I saw this on a sid system with dpkg 1.19.0.4 installed (piecemeal upgrades).

But stable has 1.19.7 already.

> But people might hit it while upgrading from oldstable to the next release?

They normally should upgrade to a stable, too. And skipping buster and
doing stretch -> bullseye is not supported.

But I can add a (Pre-)Depends: I guess...

Regards,

Rene

Bug#951111: libreoffice: it is impossible to saveas in a directory unless it is a leaf directory

[Rene Engelhard]

Hi,

On Wed, Feb 12, 2020 at 09:35:20AM +0100, fulvio ciriaco wrote:
> I understood from the text shown by reportbug about libreoffice that 
> comparing to the
> native version was required or preferred, maybe I was not able to understand 
> it, or maybe
> it is written wrong or maybe more hints are needed.

Yeah, sorry, there have been "you broke it compared to upstream" bugs
lately and telling it was a Debian bug whiereas it definitely was a
upstream one...

> > What desktop are you on? Which UI setting? (See Tools->About, maybe, if
> > you have no clue). Did you force gtk2 somehow and this is an other
> > incarnation of #951060.
> > 
> 
> I am on icewm from debian testing. There is no tools->about, but help->about 
> recites:

Yeah, that was meant.

> CPU threads: 4; OS: Linux 5.3; UI render: default; VCL: x11;

So LibreOffices open/save dialog..

Anyways: unreproducible

lowriter
random writer document: here just entering "a".
Save as
[I am on /home/rene, which has gazillions of subdirs]
enter abc.odt
LO saves as abc.odt *in /home/rene*, which is what is expected.

Regards,

Rene

Bug#951149: libreoffice-base: Missing versioned dependency on dpkg?

[Rene Engelhard]

notfound 951149 1:6.3.4-2
foun 951149 1:6.4.0~beta1-2
tag 951149 + moreinfo
thanks

Hi,

On Tue, Feb 11, 2020 at 11:03:57AM -0800, Peter Eckersley wrote:
> (Reading database ... 405556 files and directories currently installed.)
> Preparing to unpack .../libreoffice-base_1%3a6.4.1~rc1-2_amd64.deb ...
> dpkg-divert: error: unknown option --no-rename

MMh.

Which dpkg version?

Since stable has a suitable dpkg.

rene@frodo:~$ dpkg -l dpkg
Gewünscht=Unbekannt/Installieren/R=Entfernen/P=Vollständig Löschen/Halten
| Status=Nicht/Installiert/Config/U=Entpackt/halb konFiguriert/
 Halb installiert/Trigger erWartet/Trigger anhängig
|/ Fehler?=(kein)/R=Neuinstallation notwendig (Status, Fehler: GROSS=schlecht)
||/ Name   Version  Architektur  Beschreibung
+++-==---=
ii  dpkg   1.19.7   amd64Debian package management system
rene@frodo:~$ dpkg-divert --help | grep rename
  --rename Datei tatsächlich beiseite schieben (oder zurück).
  --no-rename  Datei nicht beiseite (oder zurück) schieben 
(Vorgabe).
rene@frodo:~$ ^C
rene@frodo:~$ LANG=C
rene@frodo:~$ cat /etc/debian_version 
10.3
rene@frodo:~$ dpkg -l dpkg
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name   Version  Architecture Description
+++-==---=
ii  dpkg   1.19.7   amd64Debian package management system
rene@frodo:~$ dpkg-divert --help | grep rename
  --rename actually move the file aside (or back).
  --no-rename  do not move the file aside (or back) (default).

(and thus my upgrade, and even apt -t buster-backports install) just worked.

Regards,

Rene

Bug#951111: libreoffice: it is impossible to saveas in a directory unless it is a leaf directory

[Rene Engelhard]

tag 95 + moreinfo
tag 95 + unreproducible
thanks

On Tue, Feb 11, 2020 at 10:38:31AM +0100, fulvio ciriaco wrote:
> The saveas dialog always select the first subdirectory of the current one,
> if I press  the dialogue simple brings me to the next subdirectory.

Can't reproduce this. Tried with "gen" ("use LibreOffice dialogs" in the
options, gtk3 and kde5).

> I freshly installed libreoffice 6.4.0 from  
> LibreOffice_6.4.0_Linux_x86-64_rpm.tar.gz
> at the libreoffice site and it behaves correctly, i.e. there is no 
> subdirectory
> autoselection.

And comparing apples with pies doesn't help. And we don't patch that
code. 

What desktop are you on? Which UI setting? (See Tools->About, maybe, if
you have no clue). Did you force gtk2 somehow and this is an other
incarnation of #951060.

Regards,

Rene

Bug#820081: libreoffice-writer: can't open LibreOffice Writer

[Rene Engelhard]

On Mon, Feb 10, 2020 at 05:45:30PM +0100, Jan Jona Javoršek wrote:
>I can confirm the same bug with the now current 6.1.5-3+rpi1+deb10u5

And this is not raspbian. And in Debian there's no +rpi1+

>I can attach strace and package info if necessary, but it looks related to
>gtk3 theme integration.

Honestly, I don't care, unless it happens with proper Debian, too.

And then it'd be important if it happens with default theme or whether
you use a special(tm) theme. Since there was no overwhelming reports of
it not starting since the buster release, I'd assume - if it happens at
all - doesn*'t happen all times.

Regards,

Rene

Bug#951060: libreoffice-writer: Please make the package modify the user config while settings if a setting is deprecated

[Rene Engelhard]

Hi,

On Mon, Feb 10, 2020 at 03:29:21PM +0100, Jean-Philippe MENGUAL wrote:
> So far, I checked the box "Save and Open dialogs" in Tools - Custimize- 
> general
> tab. Lo decided not maintaining this dialog and using GTK ones only.

Wrong.

> They removed the checkbox, but the setting stays existing il LO.

No, they didn't? I have it here.

Maybe you somehow forced the desktop/VCLPlug to gtk2 (which indeed got
removed upstream)?

If you did so in the dialog that is and was always bad. There's envvars
and desktop detection and even in buster one should have used gtk3 (yes,
I know xfce uses gtk2 in buster) :-)

> I propose Debian, as a distributor, to include in its setting of the package 
> the
> removal of the deprecated settings and status to ensure the end-user will have
> the GTK box, instead of a kind of transition between the old and new ones.

I propose people setting stuff sensibly ;)

Regards,

Rene

Bug#950833: Missing Breaks/Replaces between libreoffice-help-common and libreoffice-help-fr?

[Rene Engelhard]

Hi,

On Fri, Feb 07, 2020 at 10:10:24AM +0100, rene.engelh...@mailbox.org wrote:
> >Looks like there is a missing Breaks/Replaces between
> >libreoffice-help-common and libreoffice-help-fr?
> 
> Looks like those localized pngs moved packages unexpectedly...
> 
> Will look...

Caused by
https://cgit.freedesktop.org/libreoffice/help/commit/?h=libreoffice-6-4-1=191058eba782a34dad89959d5a20d6f2edd4bc3a

(and I don't check help/ routinely, while I check core/ for commits.)

Regards,

Rene

Bug#950833: Missing Breaks/Replaces between libreoffice-help-common and libreoffice-help-fr?

[rene . engelhard]

Ji,

Am 7. Februar 2020 09:47:30 MEZ schrieb Laurent Bigonville :
>While updating a system (partially up-to-date), I got the following
>error:
>
>Dépaquetage de libreoffice-help-fr (1:6.4.1~rc1-1) sur (1:6.4.0-1) ...
>dpkg: erreur de traitement de l'archive
>/tmp/apt-dpkg-install-APTwY9/254-libreoffice-help-fr_1%3a6.4.1~rc1-1_all.deb
>(--unpack) :
>tentative de remplacement de
>« 
>/usr/share/libreoffice/help/media/screenshots/cui/ui/effectspage/fr/EffectsPage.png
> »,
>qui appartient aussi au paquet libreoffice-help-common 1:6.4.0-1
>dpkg-deb: erreur: coller subprocess was killed by signal (Relais brisé
>(pipe))
>

Sigh.

>Looks like there is a missing Breaks/Replaces between
>libreoffice-help-common and libreoffice-help-fr?

Looks like those localized pngs moved packages unexpectedly...

Will look...

Regards

Rene

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

Bug#950792: /usr/lib/libreoffice/program/soffice: Opening OpenOffice make Xorg crash

[Rene Engelhard]

tag 950792 + moreinfo
tag 950792 + unreproducible
thanks

Hi,

wrt Subject: You mean LibreOffice, not OpenOffice.

On Thu, Feb 06, 2020 at 04:04:36PM +0100, Nicola wrote:
> Package: libreoffice-core
> Version: 1:6.3.4-2
> Severity: important
> File: /usr/lib/libreoffice/program/soffice

Erm, No. Either File: /usr/lib/libreoffice/program/soffice or some other
package, given /usr/lib/libreoffice/program/soffice is not in -core.

> launching libreoffice make Xorg crash.

Any why do you think it's LibreOffices fault...

> >From /var/log/kern.log :
> 
> Feb  6 15:56:04 Lenovo kernel: [ 7246.351689] nouveau :01:00.0: bus: MMIO
> read of  FAULT at 619444 [ IBUS ]

.. if it's the nouveau driver causing it?

Even if LO was the only software you noticed it in, maybe it also affects
other OpenGL or graphics stuff?

> -- System Information:
> Debian Release: bullseye/sid
>   APT prefers testing
>   APT policy: (950, 'testing'), (400, 'unstable'), (300, 'experimental'), (10,
> 'stable')

No comment..

> Versions of packages libreoffice-core depends on:
> it  fontconfig  2.13.1-2+b1
   ^
> iu  fonts-opensymbol2:102.11+LibO6.4.0-1
   ^
> ii  libboost-locale1.67.0   1.67.0-17
> ii  libc6   2.29-9
> ii  libcairo2   1.16.0-4
> ii  libclucene-contribs1v5  2.3.3.4+dfsg-1+b1
> ii  libclucene-core1v5  2.3.3.4+dfsg-1+b1
> ii  libcmis-0.5-5v5 0.5.2-1
> iu  libcups22.3.1-4
   ^
> ii  libcurl3-gnutls 7.67.0-2
> ii  libdbus-1-3 1.12.16-2
> ii  libdconf1   0.34.0-2
> ii  libeot0 0.01-5+b1
> ii  libepoxy0   1.5.4-1
> ii  libexpat1   2.2.9-1
> ii  libexttextcat-2.0-0 3.4.5-1
> ii  libfontconfig1  2.13.1-2+b1
> ii  libfreetype62.10.1-2
> iu  libgcc-s1 [libgcc1] 10-20200204-1
   ^
> ii  libgcc1 1:9.2.1-25
> iu  libglib2.0-02.62.4-1+b1
   ^
> iu  libgpgmepp6 1.13.1-6
   ^
> ii  libgraphite2-3  1.3.13-11
> iu  libgstreamer-plugins-base1.0-0  1.16.2-dmo3
   ^
> ii  libgstreamer1.0-0   1.16.2-2
> ii  libharfbuzz-icu02.6.4-1
> ii  libharfbuzz0b   2.6.4-1
> ii  libhunspell-1.7-0   1.7.0-2+b1
> ii  libhyphen0  2.8.8-7
> ii  libice6 2:1.0.9-2
> ii  libicu6363.2-2
> ii  libjpeg62-turbo 1:1.5.2-2+b1
> ii  liblcms2-2  2.9-3+b1
> ii  libldap-2.4-2   2.4.48+dfsg-1+b2
> ii  libmythes-1.2-0 2:1.2.4-3+b1
> ii  libneon27-gnutls0.30.2-3
> ii  libnspr42:4.24-1
> iu  libnss3 2:3.49.1-1
   ^
> ii  libnumbertext-1.0-0 1.0.5-3
> ii  liborcus-0.15-0 0.15.3-3
> ii  libpng16-16 1.6.37-1
> ii  libpoppler820.71.0-6
> ii  librdf0 1.0.17-1.1+b1
> it  libreoffice-common  1:6.3.4-2
   ^
[...]

maybe you want to have a sane system where not various packages are
in an inconsistent state (either unpacked only or triggers pending)?

How did you get into this situation? And what did you install from sid that
it pulled the new libgcc-s1 in? And now is that related to LibreOffice?


> Versions of packages libreoffice-core recommends:
> ii  gstreamer1.0-libav 1:1.16.2-dmo2
> ii  gstreamer1.0-plugins-bad   1:1.16.2-dmo2
> iu  gstreamer1.0-plugins-base  1.16.2-dmo3
   ^
> ii  gstreamer1.0-plugins-good  1.16.2-dmo1
> ii  gstreamer1.0-plugins-ugly  1:1.16.2-dmo2


Oh, and dmo. sigh.

> ii  libpaper-utils 1.1.28+b1
> 
> libreoffice-core suggests no packages.
> 
> Versions of packages libreoffice-common depends on:
> ii  libnumbertext-data 1.0.5-3
> iu  libreoffice-style-colibre  1:6.4.0-1
   ^
> ii  libreoffice-style-tango1:6.3.4-2
> ii  ure6.3.4-2

> Versions of packages libreoffice-common suggests:
> iu  libreoffice-style-colibre [libreoffice-style]  1:6.4.0-1
   ^
> ii  libreoffice-style-tango [libreoffice-style]1:6.3.4-2
> 
> Versions of packages libreoffice-java-common depends on:
> ii  dpkg1.19.7
> it  libreoffice-common  1:6.3.4-2
   ^
> 
> Versions of packages fonts-opensymbol recommends:
> it  fontconfig  2.13.1-2+b1
   ^

See above.

And note testing has 6.4.0-1 proper since *Sunday*. So a proper
dist-upgrade should just do the right thing(tm).

That said, my test VM is already upgraded but I tried to replicate this
on buster with buster.backports and the 6.4.0 backport which is in
backports-new:

$ sudo apt -t buster-backports install fonts-opensymbol 
libreoffice-style-colibre
Paketlisten werden gelesen... Fertig

Bug#949754: libreoffice-writer: cannot open an existing document after an update and subsequent saving (corrupt document?)

[Rene Engelhard]

found 949754 1:6.4.0~rc1-1
thanks

Hi,

On Mon, Feb 03, 2020 at 05:39:41PM +0100, Michael Stahl wrote:
> it turns out the problem was caused by adding new strings for ODF 1.3 to the
> dialog without adapting the code of the dialog; the commit
> ef39938dea14666a5835b6ae85091c1010f8ae8d was reverted before the 6.4.0.3 tag
> so only 6.4 beta and RC should be affected.

Actually beta hasn't that commit, so just rc1 and rc2, basically.

Regards,

Rene

Bug#917927: Bug#916846: [libreoffice-ogltrans] Blank screen with OpenGL transitions

[Rene Engelhard]

Hi,

On Wed, Dec 19, 2018 at 08:16:41PM +0100, Rene Engelhard wrote:
> > Please read the upstream bug report carefully. It's said there that the 
> > fault 
> 
> I read it. LO upstream is quite fast on blaming upstream bugs to
> distributions if it doesn't work on their shipped binaries - even if it
> was a bug in their code only exhibiting on newer systems with newer
> libs.

And exactly that turned out to happen.

See 
https://cgit.freedesktop.org/libreoffice/core/commit/?id=fb27784fcbd3383a7b2648714de19ae5f3818fa5

> > is in Debian version of LibreOffice, official LibreOffice debs work fine on 
> > Debian. So, LibreOffice is at fault, not system libraries.
> 
> LO ships all possible (including stuff available on every Linux) libraries 
> internally
> while we aren't. Including stuff like cairo etc.

And glm.

> So still, it can be an issue of us using some (newer) system library.

q.e.d.

Backported it to master for a 6.4.0-2 and to debian-buster-6.1.5 for a
prospective buster update...

Regards,
 
Rene

Bug#917927: [libreoffice-impress] Blank screen with OpenGL transitions

[Rene Engelhard]

Hi,

On Thu, Nov 14, 2019 at 07:56:57PM +0100, Rene Engelhard wrote:
> [...] internal libraries - and that includes libepoxy.

and glm.

Just saw 
https://cgit.freedesktop.org/libreoffice/core/commit/?id=fb27784fcbd3383a7b2648714de19ae5f3818fa5

And yes, there is glm 0.9.9.x in unstable since Jan last year and there
was https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=892861 after
all...

Backported the patch to master (for 6.4.0-2) and debian-buster-6.1.5
(for a prospective buster update)

Regards,

Rene

Bug#950225: marked as pending in libreoffice

[Rene Engelhard]

tag 950225 - pending
thanks

Hi,

On Fri, Jan 31, 2020 at 04:38:40PM +, Rene Engelhard wrote:
> Bug #950225 in libreoffice reported by you has been fixed in the
> Git repository and is awaiting an upload. You can see the commit
> message below and you can check the diff of the fix at:
> 
> https://salsa.debian.org/libreoffice-team/libreoffice/libreoffice/commit/b95eb65b037f97bbc169654e16759d43a21645b7
> 
> 
> debian/patches/no-packagekit-per-default.diff: fix update to 6.4 (closes: 
> #950225)
> 

Looks like this (correct) fix doesn't really help in this case, though.
Still crashes for me after installing a testbuild in my sid VM..

Regards,

Rene

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

[Rene Engelhard]

block 950319 by 928037
thanks

On Sat, Feb 01, 2020 at 08:21:20AM +0100, Frank Loeffler wrote:
> in the mailcap is able to prevent shell escapes. This is why the replacing
> program must be the one doing this. Thus, if any tool using mailcap does not
> quote filenames properly and only relies on mailcap to do it for them, that
> would be a (security) bug within that tool.

Yes, and what happens if the MUA does not do that? Then we would
exchange a problem to an other? And given that the actual user base of
LO will probably use more GUI MUAs than mutt I'd prefer if they keep
working.

> I agree that this is confusing. I commented on a related bug within mutt

Indeed.

> first, only later realizing that mutt actually does it the right way.
> #928037 contains thoughts about this, including links to other threads, that
> show the problem from a more or less neutral view. This is why #928037
> exists: the RFC is rather unhelpful and other documentation does not really
> show users how those entries should be handled, right now.

Let's wait what comes out of 928037  then...

Regards,

Rene

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

[Rene Engelhard]

Hi,

On Sat, Feb 01, 2020 at 08:21:20AM +0100, Frank Loeffler wrote:
> For thunderbird I find, e.g.:
> 
> message/rfc822; /usr/bin/thunderbird %s; test=test -n "$DISPLAY"
> text/calendar; /usr/bin/thunderbird %s; test=test -n "$DISPLAY"
> text/x-vcard; /usr/bin/thunderbird %s; test=test -n "$DISPLAY"
> 
> firefox:
> 
> text/html; /usr/bin/firefox-esr %s; description=HTML Text; test=test -n
> "$DISPLAY";  nametemplate=%s.html
> text/xml; /usr/bin/firefox-esr %s; description=XML Text; test=test -n
> "$DISPLAY";  nametemplate=%s.xml
> 
> evolution:
> 
> text/calendar; evolution -c tasks %s; test=test -n "$DISPLAY"
> text/x-vcard; evolution -c tasks %s; test=test -n "$DISPLAY"
> text/directory; evolution -c tasks %s; test=test -n "$DISPLAY"
> 
> None of these tools use quotes.

And none of these is my point.

My point is how evolution and thundebird handle %s when opening
documents linke in your case with mutt - not them itself for
messages, vcards etc.

Regards,

Rene

Bug#949754: libreoffice-writer: cannot open an existing document after an update and subsequent saving (corrupt document?)

[Rene Engelhard]

On Fri, Jan 31, 2020 at 07:49:09PM +0100, Antonio wrote:
> I don't remember changing anything, I only used basic functions like
> open, edit, save etc ... and updated the package when available in the
> debian / sid repository.

Hmm, ok.

You missed to answer 

> > As said above, did you change the ODF save version once? And how? And what 
> > does the combo-box look like?
  
^
   this.
as also asked for by upstream:

> 19:34 < mst___> _rene_, maybe ask him if he remembers how he set this
> value, or if it shows up as smoething other than empty combo-box in   
> 
> Load/Save->General->ODF format version
>  

though :)

Regards,

Rene

P.S.: And please use proper mail quoting. Top-Posting and fullquote
after it is NOT.

Bug#949754: libreoffice-writer: cannot open an existing document after an update and subsequent saving (corrupt document?)

[Rene Engelhard]

forwarded 949754 Michael Stahl 
tag 949754 - unreproducible
thanks

Hi,

On Fri, Jan 31, 2020 at 07:08:53PM +0100, Antonio wrote:
> the problem is in this line:
> 
>  oor:name="DefaultVersion" oor:op="fuse">0

aha. ok, as I guessed, ODF format...

Do you remember changing the ODF default save version once?

> I think it would be preferable to remove it (or modify it
> appropriately) after installing the package ...

For upstream LO code, yes. As said, going over all homes and removing
this line in maintainer scripts is a no-go.

Just asked on IRC (also Cced):

19:24 < _rene_> mst___: bugs.debian.org/949754. known?
19:24 < _rene_> mst___: something which should be handled in LO code?
19:24 < mst___> shivam_, yes that is expected, translations repo is large
19:24 -!- mebasoglu [~mebasoglu@81.214.161.7] has joined #libreoffice-dev
19:24 -!- MechtiIde [~Mechtilde@2a02:2788:1004:59a::16] has joined 
#libreoffice-dev
19:25 < mst___> _rene_, that sounds like a very serious bug
19:25 < _rene_> mst___: yup...
19:25 < _rene_> mst___: no idea what the value he has means, though
19:25 < _rene_> mst___: that's why I ask :)
19:25 < mst___> i'd be very interested how to reproduce that
19:26 < _rene_> probably he changed some setting?
19:26 < _rene_> and then upgraded to 6.4 which doesn't like that setting?
19:26 < _rene_> it's registrymodifications.xcu. ttbomk that holds changed user 
settings compared to the default?
19:27 < mst___> ah he says this is the problem:  oor:name="DefaultVersion" 
oor:op="fuse">0
19:27 < mst___> iirc that's the ODF version in tools->options
19:27 < mst___> probably 0 is the oldest one?
19:29 < _rene_> I don't know, I assumed you do :)
19:29 < mst___> ah no 0 is "ODFVER_UNKNOWN" - wtf is that?
19:30 -!- dtardon [~dtar...@ip-89-177-152-132.net.upcbroadband.cz] has quit 
[Ping timeout: 268 seconds]
19:31 < _rene_> mst___: if you want me to ask him something, can do
19:32 < _rene_> I am already asking him whether he remembers setting ODF save 
settings
19:32 < mst___> uh i dont get it, there is no constant there for odf 1.2 
extended or 1.2 extended(compatibility) - would need some investigation what is 
the 
mapping between the dialog and the configuration
19:33 < mst___> lol ... i write that into registrymodfications.xcu and the 
dialog shows an empty combobox
19:34 < mst___> _rene_, maybe ask him if he remembers how he set this value, or 
if it shows up as smoething other than empty combo-box in 
Load/Save->General->ODF format version
19:34 <@jmux> Any reason why ODFDefaultVersion has no 1.3 but 
ODFSaneDefaultVersion has?
19:34 < _rene_> ok, mind pasting this conversation?
19:34 < _rene_> (for reference)

As said above, did you change the ODF save version once? And how? And what does 
the combo-box look like?

Regards,

Rene

Bug#949754: libreoffice-writer: cannot open an existing document after an update and subsequent saving (corrupt document?)

[Rene Engelhard]

tag 949754 + moreinfo
tag 949754 + unreproducible
thanks

On Fri, Jan 24, 2020 at 07:39:16PM +0100, Antonio wrote:
> After several tests I found that the problem depended on the
> libreoffice user profile of the previous installed version.

Hrm.

> To solve this problem I manually removed the file:
> $ rm  -f /home/user/.config/libreoffice/4/user/registrymodifications.xcu

It would have been interesting *what* entry there caused the problem.
Maybe some export/filter option? Or ODF  compatibility? 

> which will then be recreated when the program restarts.

With default values.

> Perhaps could be evaluated an action in the installation trigger of
> the new version to avoid this eventuality...

If so, only in the application, not in maintainer scripts since $HOME is
a no-go for them.

In any case: one needs to know a config item to fix. 

Regards,

Rene

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

[Rene Engelhard]

found 950319 1:5.2.3~rc1-3
thanks

Hi,

On Fri, Jan 31, 2020 at 11:47:29AM +0100, Frank Loeffler wrote:
> Using mutt, I created a new email, added an attachment with a file name
> containing spaces (a pptx file, thus libreoffice), and without sending

no, MS Office. Which LibreOffice happens to be registered for.

> What happened is that, as it should, mutt properly quoted whatever it
> was replacing %s with, in that case using single quote. So, in effect,
> the following command was executed:
> 
> 
> soffice --nologo --writer ''file with spaces''
> 
> And since '' is starting and immediately ending the quotation,
> libreoffice saw three arguments.
> 
>* What outcome did you expect instead?
> 
> The filename should have been given as one argument to libreoffice.

Just that mutt is one thing. Maybe mutt does it correct, but
unfortunately mutt users are not really the majority, people use
thunderbird or evolution or so...

(I use mutt, but via ssh, and no X on that rpi3 anyways.)

> Following #928037 and references therein, I believe that the correct
> solution is to not use '%s' in the mime files distributed with the
> Debian packages: it should just be a simple %s, no quotes. Quoting is
> the task of the program replacing %s.

Did you check thunderbird and evolution?

Regards,

Rene

Bug#950225: libreoffice-writer: Immediate crash lunching mail merge wizard

[Rene Engelhard]

retitle 950225 libreoffice-writer: Immediate crash lunching mail merge wizard 
if libreoffice-base not installed
thanks

Hi,

On Thu, Jan 30, 2020 at 06:57:14PM +0100, Rene Engelhard wrote:
> > ii  libreoffice-base-core1:6.4.0-1

Looked into the past.

libreoffice-base-core (well, openoffice.org-base-core) came into
existence long ago:

 openoffice.org (1:2.3.1-1) unstable; urgency=low
[...]
   * debian/control.in, debian/rules:
 - put libdba680l?.so into a -base-core package. Make -base, -writer and
   -calc depend on it (closes: #381083)
[...]

See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=381083.

Looks like it needs more now or something else broke?

Regards,
 
Rene

Bug#950225: libreoffice-writer: Immediate crash lunching mail merge wizard

[Rene Engelhard]

Hi,

On Thu, Jan 30, 2020 at 11:38:31AM +0100, Cesare Leonardi wrote:
> As soon as I click to start the wizard, LibreOffice closes and the Document
> Recovery window open up saying: "Due to an error, LibreOffice crashed..."
> Then the recovery process starts.

Mmh.

Indeed.

A 6.3.4-1 from bpo complains about Base not being installed when I try
to do what you did on a system where I deinstalled libreoffice-base
first.
A 6.4.0 crashes, as you say.

> I've never used the mail merge function before, so I don't know if it
> worked with previous LibreOffice versions.

It should not have changed considerably.

> I've never installed Java and I prefer to not have to. And searching around
> I've not found evidence that this function depends on Java: I've read it's
> written in python. Please, tell me if I'm wrong.

It depends. As long as the internal db comes into play there's Java
involved.

What is supposed to be your data source?

> ii  libreoffice-base-core1:6.4.0-1

What about libreoffice-base?

(That's why libreoffice depends on base, and that is why
libreoffice-writer suggests -base.)

What happens if you install -base? Maybe select a specific driver so you
don't get -sdbc-hsqldb (Java-based, thus depending on Java) per
default...

Regards,

Rene

Bug#949278: libreoffice hangs at startup if ~/.libreoffice folder does not exist

[Rene Engelhard]

retitle 949278 endless loop if ~/.config/libreoffice is a symlink
severity 949278 minor
thanks

Hi,

On Mon, Jan 20, 2020 at 09:22:55PM +0100, Pierre Bernhardt wrote:
> Am 20.01.20 um 11:14 schrieb Rene Engelhard:
> > You mean keep the .config/libreoffice and remove the old .libreoffice.
> 
> No, really mean remove the link .config/libreoffice which points to 
> .libreoffice,
> remove .libreoffice

Exactly my point.

Remove the bogus link and let the "correct" one be generated.

> and then next start .config/libreoffice will be recreated by starting 
> libreoffice.

Indeed.

> However the loop itself is a bug and a symlink is not an error.

But you are not supposed to play tricks in stuff the applications
do not expect either. User config is tricky in this regard and this is
not a "save space" thing either. In fact, .config/libreoffice ->
.libreoffice was always wrongdoing to begin with.

As shown in the commits there is upstream migration code for this and
there was no need for any symlink here.
And the migration code LO 3 -> LO 4+ (or .libreoffice ->
.config/libreoffice) needs to know what it can expect.

> It is a regular tool to point to another place whenever it is wanted. Each 
> software should deal
> with them and if it is not allowed/supported, it should show a message e.g.
> displayed by an exception handling. But supporting a symlink is not really
> hard to support.

This case would then need a "way out" of a migration.

For a migration which happened almost two decades ago.

I don't believe upstream will invest time in this - they have more
important stuff on the plate...

> PS: Don't know how long the .libreoffice folder exists. It could be very long
> in the past maybe before libreoffice has to been forked from openoffice. Maybe
> I renamed/copied it from .openoffice to .libreoffice or whatever. But let us

LO 3.x (first LO was 3.3) did .libreoffice initially (as it was forked from 
OpenOffice.org)
until it was renamed to .config/libreoffice in 2011 (see my referenced
commit)

Anyway, will try myself in a VM...

Regards,

Rene

Bug#949278: libreoffice hangs at startup if ~/.libreoffice folder does not exist

[Rene Engelhard]

On Sun, Jan 19, 2020 at 10:50:57PM +0100, Pierre Bernhardt wrote:
> > That would mean that it always hanged on a new
> > install where .libreoffice (actually that one doesn't exist, you mean
> > .config/libreoffice) doesn't exist.
> 
> No, it is really my /home/user/.libreoffice folder which should normally
> held users profile.

No, it doesn't. Not since 2011/2012.

https://cgit.freedesktop.org/libreoffice/core/commit/?id=9276f7d5740a28b342db2a9bcd8644ff2f4f5742
and
https://cgit.freedesktop.org/libreoffice/core/commit/?id=c82b6096efb856220b8d1dafd9ba3e1f167e2d89

> [pid 129252] mkdir("/home/pierre/.config/libreoffice/4", 0777) = -1 ENOENT 
> (Datei oder Verzeichnis nicht gefunden)

.config/libreoffice. As I said.

> Checking .config/libreoffice shows me that this is a link to ../.libreoffice
> folder:
> 
> user@nihilnihil:~$ ls -l /home/user/.config/libreoffice
> lrwxrwxrwx 1 user user 15 Jun 14  2012 /home/user/.config/libreoffice -> 
> ../.libreoffice

Why?

> As you can see it is really old aged link installed in the past.

You yourself created it? I somehow don't believe LibreOffice did. And the link
is the wrong way round in any case.

At least I don't find ymlink code in 6.1.x. Didn't look back in older releases.

> So workaround is to remove the old .config/libreoffice link will help.

You mean keep the .config/libreoffice and remove the old .libreoffice.

Regards,

Rene

Bug#949278: libreoffice hangs at startup if ~/.libreoffice folder does not exist

[Rene Engelhard]

tag 949278 + moreinfo
tag 949278 + unreproducible
thanks

On Sun, Jan 19, 2020 at 10:00:37AM +0100, Pierre Bernhardt wrote:
> after removing my .libreoffice directory it will not startup fully any more.
> The splash screen is shown ever and than it hangs as long I press Ctrl-C to
> abort.
> 
> I found a workaround by manually recreating simply the .libreoffice folder.
> 
> I can reproduce the problem each time I remove or rename the .libreoffice
> folder.

That's impossible.

That would mean that it always hanged on a new
install where .libreoffice (actually that one doesn't exist, you mean
.config/libreoffice) doesn't exist.

Which does not happen.

Do you have some broken network config? I.e. a broken "lo" (loopback) interface?

Regards,

Rene

Re: KDE file dialog in Libreoffice

[Rene Engelhard]

On Sat, Jan 18, 2020 at 06:49:23PM +0100, Rainer Dorsch wrote:
> is there a way to get the KDE file dialog in libreoffice (buster-backports) ?

> 
> Installing libreoffice-kde does not seem to be sufficient for me...

libreoffice-kde5?

$ rmadison libreoffice-kde
libreoffice-kde | 1:4.3.3-2+deb8u11| oldoldstable   | 
amd64, armel, armhf, i386
libreoffice-kde | 1:5.2.7-1+deb9u10| oldstable  | 
amd64, arm64, armel, armhf, i386, mips, mips64el, mipsel, ppc64el, s390x
libreoffice-kde | 1:5.2.7-1+deb9u11| oldstable-proposed-updates | 
amd64, arm64, armel, armhf, i386, mips, mips64el, mipsel, ppc64el, s390x
libreoffice-kde | 1:6.1.5-3+deb10u4~bpo9+1 | stretch-backports  | all
libreoffice-kde | 1:6.1.5-3+deb10u5| stable | all
$ rmadison libreoffice-kde5
libreoffice-kde5 | 1:6.1.5-3+deb10u4~bpo9+1  | stretch-backports | amd64, 
arm64, armel, armhf, i386, mips, mips64el, mipsel, ppc64el, s390x
libreoffice-kde5 | 1:6.1.5-3+deb10u5 | stable| amd64, 
arm64, armel, armhf, i386, mips, mips64el, mipsel, ppc64el, s390x
libreoffice-kde5 | 1:6.3.4-2~bpo10+1 | buster-backports  | amd64, 
arm64, armel, armhf, i386, mips, mips64el, mipsel, ppc64el, s390x
libreoffice-kde5 | 1:6.3.4-2 | testing   | amd64, 
arm64, armel, armhf, i386, mips64el, mipsel, ppc64el, s390x
libreoffice-kde5 | 1:6.3.4-2 | unstable  | arm64
libreoffice-kde5 | 1:6.4.0~beta1-0reprotest1 | experimental  | arm64, 
armel, armhf, mips64el, mipsel
libreoffice-kde5 | 1:6.4.0~beta1-4   | experimental  | amd64, i386, 
ppc64el, s390x
libreoffice-kde5 | 1:6.4.0~rc2-2 | unstable  | amd64, 
armel, armhf, i386, mips64el, mipsel, ppc64el, s390x
$

libreoffice-kde is a noop just depending on -kde5 (and not present in 
buster-backports since it was
just in buster for stretch->buster updates).

Regards,

Rene

Bug#948120: libreoffice: Incorrect conditional test to enable BUILD_NOGUI_PACKAGES

[Rene Engelhard]

On Sat, Jan 04, 2020 at 03:15:02PM +0100, John Paul Adrian Glaubitz wrote:
> Feel free to do the same for powerpc as the build machine
> for ppc64 and powerpc is the same and the new one for
> both architectures will be even faster.

No, powerpc in 32bits is dead.

And I even enabled i386 there only because ... i386.

> And I think it's probably a good idea to check all occurrences
> of "findstring" in debian/rules to make sure that it really
> matches the strings that you intended to match.

Did that some time ago, fixed all problematic ones in

libreoffice (1:6.2.3~rc2-1) experimental; urgency=medium

  * New upstream release candidate

  * debian/rules:
- replace various $(findstring for arch checks by $(filter

 -- Rene Engelhard   Tue, 16 Apr 2019 22:25:38 +0200

This one sneaked in when doing -nogui in 6.4.x, and

$ grep findstring * | grep ARCHS
grep: branding: Ist ein Verzeichnis
grep: patches: Ist ein Verzeichnis
grep: scripts: Ist ein Verzeichnis
rules:ifeq (ia64,$(findstring ia64,$(OOO_OPENJDK_ARCHS)))
grep: source: Ist ein Verzeichnis
grep: stampdir: Ist ein Verzeichnis
grep: templates: Ist ein Verzeichnis
grep: tests: Ist ein Verzeichnis
grep: upstream: Ist ein Verzeichnis

only was missed. (another obsolete architecture...)

Regards,

Rene

Bug#948120: libreoffice: Incorrect conditional test to enable BUILD_NOGUI_PACKAGES

[Rene Engelhard]

Hi,

On Sat, Jan 04, 2020 at 02:33:51PM +0100, John Paul Adrian Glaubitz wrote:
> On 1/4/20 2:28 PM, Rene Engelhard wrote:
> > That just means that BUILD_NOGUI_PACKAGES=n is set and the nogui part is 
> > not even tried.
> > ppc64 is fast and has server uses, so should definitel get -nogui.
> 
> That might be the case. But ppc64 is currently *not* in the list
> of OOO_NOGUI_ARCH. Yet your rules file was executing parts of
> the code as if it was in OOO_NOGUI_ARCH.

Yes, because BUILD_NOGUI_PACKAGES=y is set because of findstring vs. filter.

There you *are* right, I didn't say anything else.



> > I am not mistaken:
> > 
> > No, this is just a workaround. The real fix would imho be to find out
> > why .desktop is not present when it's tried to be removed..
> 
> What? I'm not sure why this would be a workaround.

But that just disables -nogui there which is not what we want
-> workaround.
Non-workaround would be to fix OOO_NOGUI_ARCHS to have ppc64.

> You didn't put ppc64 in the list of NOGUI architectures.

Yes, because I didn't have it in radar when I did this.

> That means the nogui code itself wasn't build.

Erm, no. Not at the stage of the failure.

The cause of build is as follows:
 1 if BUILD_NOGUI_PACKAGES=y build LO with --disable-gui
 1a save the built tree
 2 build LO normally without --disable-gui
( 3 build the tests and run them, if enabled )
( 4 build languages etc, only -A or -b case )
 5 make install
 6 if BUILD_NOGUI_PACKAGES=y:
a copy core to core-nogui etc
b replace files in -core-nogui with the files built in 1 and
  saved in 1a and remove files present in -core but not in
  -core-nogui
c remove lib*ui.so
d remove .desktop

d fails.

And a build log clearly shows 1,1a,2,5 done.

Though because ppc64el is not in the -core-nogui packages' arch list
it's not copied:

>From the build log:

[...]
# create no-GUI packages
for p in report-builder-bin; do \
rm -rf debian/libreoffice-$p-nogui; \
cp -ra debian/libreoffice-$p debian/libreoffice-$p-nogui; \
for i in debian/libreoffice-$p-nogui/usr/lib/libreoffice/program/*; do \
if [ -e instdir-nogui/program/`basename $i` ]; then \
cp -v instdir-nogui/program/`basename $i` \

debian/libreoffice-$p-nogui/usr/lib/libreoffice/program; \
else \
rm -fv 
debian/libreoffice-$p-nogui/usr/lib/libreoffice/program/`basename $i`; \
fi; \
done; \
done
'instdir-nogui/program/librptlo.so' - 
'debian/libreoffice-report-builder-bin-nogui/usr/lib/libreoffice/program/librptlo.so'
'instdir-nogui/program/librptuilo.so' - 
'debian/libreoffice-report-builder-bin-nogui/usr/lib/libreoffice/program/librptuilo.so'
'instdir-nogui/program/librptxmllo.so' - 
'debian/libreoffice-report-builder-bin-nogui/usr/lib/libreoffice/program/librptxmllo.so'
# remove lib*uilo.so in --nogui
find debian/libreoffice-*-nogui/usr/lib/libreoffice/program/lib*uilo.so -exec 
rm {} \;
# and (no UI, so not needed) not needed .desktop files
find debian/libreoffice-*-nogui/usr/share/applications/*.desktop -exec rm {} \;
find: ‘debian/libreoffice-*-nogui/usr/share/applications/*.desktop’: No such 
file or directory
make: *** [debian/rules:2699: debian/stampdir/install-arch] Error 1
dpkg-buildpackage: error: fakeroot debian/rules binary-arch subprocess returned 
exit status 2

Note the loop missing -core, -writer, -calc etc which is the packages having a 
.desktop file,
so the rm doesn't find anything and fails.

> You want to use "filter" when looking for architectures, not "findstring"
> which will match "ppc64" in "ppc64el".

Maybe, yes. But in fact ppc64 should be added to OOO_NOGUI_ARCHS anyways, which 
is
the real issue here.

Regards,

Rene

Bug#948120: libreoffice: Incorrect conditional test to enable BUILD_NOGUI_PACKAGES

[Rene Engelhard]

Hi,

On Sat, Jan 04, 2020 at 02:07:36PM +0100, John Paul Adrian Glaubitz wrote:
> On 1/4/20 10:19 AM, John Paul Adrian Glaubitz wrote:
> > I haven't verified it, but my suspicion is that the following conditional 
> > test is
> > incorrect as the function findstring will match "ppc64" in OOO_NOGUI_ARCHS 
> > if
> > it contains "ppc64el":
> > 
> > ifeq "$(ENABLE_GUI)" "y"
> >   ifneq (,$(findstring $(DEB_HOST_ARCH),$(OOO_NOGUI_ARCHS)))
> > BUILD_NOGUI_PACKAGES=y
> >   endif
> > else
> I can confirm that replacing "findstring" with "filter" here fixes the build
> on ppc64.

That just means that BUILD_NOGUI_PACKAGES=n is set and the nogui part is not 
even tried.
ppc64 is fast and has server uses, so should definitel get -nogui.

I am not mistaken:

No, this is just a workaround. The real fix would imho be to find out
why .desktop is not present when it's tried to be removed..

Regards,

Rene

Bug#948120: libreoffice: Incorrect conditional test to enable BUILD_NOGUI_PACKAGES

[Rene Engelhard]

On Sat, Jan 04, 2020 at 10:19:13AM +0100, John Paul Adrian Glaubitz wrote:
> The build on ppc64 currently fails because debian/rules tries to execute some
> script code on ppc64 which is relevant for the OOO_NOGUI_ARCHS in 
> debian/rules.

Yes.

> # remove lib*uilo.so in --nogui
> find debian/libreoffice-*-nogui/usr/lib/libreoffice/program/lib*uilo.so -exec 
> rm {} \;

Note this works. Even when it is also operating on -nogui.

> # and (no UI, so not needed) not needed .desktop files
> find debian/libreoffice-*-nogui/usr/share/applications/*.desktop -exec rm {} 
> \;
> find: ‘debian/libreoffice-*-nogui/usr/share/applications/*.desktop’: No such 
> file or directory

And this not.

(And -nogui starts from a cp -ra from the "normal" packages.)

> make: *** [debian/rules:2699: debian/stampdir/install-arch] Error 1
> 
> I haven't verified it, but my suspicion is that the following conditional 
> test is
> incorrect as the function findstring will match "ppc64" in OOO_NOGUI_ARCHS if
> it contains "ppc64el":

But...

> ifeq "$(ENABLE_GUI)" "y"
>   ifneq (,$(findstring $(DEB_HOST_ARCH),$(OOO_NOGUI_ARCHS)))
> BUILD_NOGUI_PACKAGES=y
>   endif
> else

... this is just for "build -nogui *in addition* to the 'normal' packages".
In the "normal" packages .desktop should have been present so the find -exec rm
should work

> So, I suggest to use the function "filter" instead of "findstring" to fix this
> conditional test.

Maybe, but that (afaics) doesn't fix the real issue?

Regards,

Rene

Bug#947907: trying to overwrite '/usr/share/java/juh.jar', which is also in package libjuh-java

[Rene Engelhard]

Hi,

On Fri, Jan 03, 2020 at 06:00:49PM +, Christopher Obbard wrote:
> On Fri, 3 Jan 2020 at 17:52, Rene Engelhard  wrote:
> >
> > Hi,
> >
> > On Fri, Jan 03, 2020 at 06:36:56PM +0100, Rene Engelhard wrote:
> > > > The following additional packages will be installed:
> > > >libjuh-java libjurt-java libridl-java libunoloader-java
> > > > The following NEW packages will be installed:
> > > >libjuh-java libjurt-java libridl-java libunoloader-java
> > [...]
> >
> > I wonder how you got into this. Looks you didn't upgrade to 6.4 yet
> > before so that it does flag libjuh-java libjurt-java libridl-java
> > libunoloader-java as *additional* packages?
> 
> those four depends appear to be coming from the upgrade of
> libreoffice-java-common

Yes, but from libreoffice-java-common 6.3.x -> 6.4.x and that only
because libreoffice-java-common gained explicit dependencies on them
since they "obviously" are needed for the Java stuff :-)

(They formerly were in "ure", and are supposed to be moved to the extra
packages - they "survived" in ure which gives us this mess.)

> libreoffice has been upgraded to the latest version

If you mean the actual "libreoffice" package. That has no contents and
is empty and it doesn't force any version except for libreoffice-core
(which I don't remember the rationale for, but there must have been
some). So it can usually be ignored ;-)

> the dist-upgrade won't work until the four packages are installed,
> which won't happen because they conflict with ure... which is required
> by most of the libreoffice suite :-)

True... :-)

Regards,

Rene
> 

Bug#947907: trying to overwrite '/usr/share/java/juh.jar', which is also in package libjuh-java

[Rene Engelhard]

Hi,

On Fri, Jan 03, 2020 at 06:36:56PM +0100, Rene Engelhard wrote:
> > The following additional packages will be installed:
> >libjuh-java libjurt-java libridl-java libunoloader-java
> > The following NEW packages will be installed:
> >libjuh-java libjurt-java libridl-java libunoloader-java
[...]

I wonder how you got into this. Looks you didn't upgrade to 6.4 yet
before so that it does flag libjuh-java libjurt-java libridl-java
libunoloader-java as *additional* packages?

> I am not sure what a dist-upgrade will do here and Replaces: vice-versa
> might be problematic, so it might be you need to upgrade ure when it is
> available and then continue with a normal upgrade (maybe it even works
> in one -f or dist-upgrade, but not sure).

Actually #debian-devel says it should work, so let's test...

Regards,

Rene

Bug#947907: trying to overwrite '/usr/share/java/juh.jar', which is also in package libjuh-java

[Rene Engelhard]

Hi,

On Fri, Jan 03, 2020 at 05:00:37PM +, Christopher Obbard wrote:
> $ sudo apt --fix-broken install
> Reading package lists... Done
> Building dependency tree
> Reading state information... Done
> Correcting dependencies... Done
> The following packages were automatically installed and are no longer
> required:
>coinor-libcbc3 coinor-libcgl1 coinor-libclp1 coinor-libcoinmp1v5
> coinor-libcoinutils3v5 coinor-libosi1v5
> Use 'sudo apt autoremove' to remove them.
> The following additional packages will be installed:
>libjuh-java libjurt-java libridl-java libunoloader-java
> The following NEW packages will be installed:
>libjuh-java libjurt-java libridl-java libunoloader-java
> 0 upgraded, 4 newly installed, 0 to remove and 123 not upgraded.
> 37 not fully installed or removed.
> Need to get 0 B/1,138 kB of archives.
> After this operation, 1,351 kB of additional disk space will be used.
> Do you want to continue? [Y/n]
> (Reading database ... 124615 files and directories currently installed.)
> Preparing to unpack .../libjuh-java_1%3a6.4.0~rc1-5_all.deb ...
> Unpacking libjuh-java (1:6.4.0~rc1-5) ...
> dpkg: error processing archive
> /var/cache/apt/archives/libjuh-java_1%3a6.4.0~rc1-5_all.deb (--unpack):
>   trying to overwrite '/usr/share/java/juh.jar', which is also in
> package ure 6.4.0~rc1-5
> Preparing to unpack .../libjurt-java_1%3a6.4.0~rc1-5_all.deb ...
> Unpacking libjurt-java (1:6.4.0~rc1-5) ...
> dpkg: error processing archive
> /var/cache/apt/archives/libjurt-java_1%3a6.4.0~rc1-5_all.deb (--unpack):
>   trying to overwrite '/usr/share/java/jurt.jar', which is also in
> package ure 6.4.0~rc1-5
> Preparing to unpack .../libridl-java_1%3a6.4.0~rc1-5_all.deb ...
> Unpacking libridl-java (1:6.4.0~rc1-5) ...
> dpkg: error processing archive
> /var/cache/apt/archives/libridl-java_1%3a6.4.0~rc1-5_all.deb (--unpack):
>   trying to overwrite '/usr/share/java/ridl.jar', which is also in
> package ure 6.4.0~rc1-5
> Preparing to unpack .../libunoloader-java_1%3a6.4.0~rc1-5_all.deb ...
> Unpacking libunoloader-java (1:6.4.0~rc1-5) ...
> dpkg: error processing archive
> /var/cache/apt/archives/libunoloader-java_1%3a6.4.0~rc1-5_all.deb
> (--unpack):
>   trying to overwrite '/usr/share/java/unoloader.jar', which is also in
> package ure 6.4.0~rc1-5
> Errors were encountered while processing:
>   /var/cache/apt/archives/libjuh-java_1%3a6.4.0~rc1-5_all.deb
>   /var/cache/apt/archives/libjurt-java_1%3a6.4.0~rc1-5_all.deb
>   /var/cache/apt/archives/libridl-java_1%3a6.4.0~rc1-5_all.deb
>   /var/cache/apt/archives/libunoloader-java_1%3a6.4.0~rc1-5_all.deb
> E: Sub-process /usr/bin/dpkg returned an error code (1)

Actually this is the other way round. But those files are correct in
those files, they will be gone from ure.

I am not sure what a dist-upgrade will do here and Replaces: vice-versa
might be problematic, so it might be you need to upgrade ure when it is
available and then continue with a normal upgrade (maybe it even works
in one -f or dist-upgrade, but not sure).

Regards,

Rene

Bug#947907: trying to overwrite '/usr/share/java/juh.jar', which is also in package libjuh-java

[Rene Engelhard]

On Fri, Jan 03, 2020 at 04:49:23PM +0100, Thorsten Glaser wrote:
> Package: ure
> Version: 6.4.0~rc1-5
> Followup-For: Bug #947907
> 
> It’s more than just libjuh-java:

Yes.

As was already said in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=947907#34 (this bug!)
and the bugs merged with it (and the corresponding commit.)

Regards,

Rene

Bug#947446: closed by Rene Engelhard (Bug#947446: fixed in libreoffice 1:6.4.0~rc1-3)

[Rene Engelhard]

notfound 947446 1:6.4.0~rc1-5
close 947446 1:6.4.0~rc1-3
thanks

On Thu, Jan 02, 2020 at 10:58:11PM +0100, Andreas Beckmann wrote:
> Control: reopen -1
> Control: found -1 1:6.4.0~rc1-5

Erm, no. Breaks:/Replaces: are present.

> it looks like ure is still shipping (some of) the files that were split 
> out to separate packages:

Yes. But this completely different to your bug which was about the
Breaks:/Replaces: being there at all. Your bug is fixed.

That the split was broken per se is an other matter, but there are
already 3 bugs wrt that:

#947907 [S|P|=] [ure] trying to overwrite '/usr/share/java/juh.jar', which is 
also in package libjuh-java
#947909 [S|P|=] [ure] ure is trying to overwrite '/usr/share/java/juh.jar', 
which is also in package libjuh-java 1:6.4.0~rc1-5
#947910 [S|P|=] [ure] ure uninstallable because of file conflict with 
libjuh-java

>   Selecting previously unselected package ure.
>   Preparing to unpack .../08-ure_6.4.0~rc1-5_amd64.deb ...
>   Unpacking ure (6.4.0~rc1-5) ...
>   dpkg: error processing archive 
> /tmp/apt-dpkg-install-p2iEE9/08-ure_6.4.0~rc1-5_amd64.deb (--unpack):
>trying to overwrite '/usr/share/java/juh.jar', which is also in package 
> libjuh-java 1:6.4.0~rc1-5
> 
> Similarily for libjurt-java, libridl-java, libunoloader-java in sid.

Yes.

> Don't forget to bump the B+R against ure to a version that is no longer
> shipping them.

https://salsa.debian.org/libreoffice-team/libreoffice/libreoffice/commit/7994273bbbe8014624b3e9001dfb7243ac18c6fd

Regards,

Rene

Bug#947907: uno-libs-private: Unmet dependencies

[rene . engelhard]

Am 2. Januar 2020 04:46:11 MEZ schrieb William Panlener :
>ure=6.4.0~rc1-5 ships files provided by other packages in addition to
>the reported conflict. I have discovered the following conflicting
>files and packages:
>
>'/usr/share/java/juh.jar', which is also in package libjuh-java
>1:6.4.0~rc1-5
>'/usr/share/java/jurt.jar', which is also in package libjurt-java
>1:6.4.0~rc1-5
>'/usr/share/java/ridl.jar', which is also in package libridl-java
>1:6.4.0~rc1-5
>'/usr/share/java/unoloader.jar', which is also in package
>libunoloader-java 1:6.4.0~rc1-5

I know.

Already fixed locally, needs a test build ...

Regards

Rene

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

Bug#947907: uno-libs-private: Unmet dependencies

[Rene Engelhard]

reassign 947907 ure
severity 947907 serious
retitle 947907 trying to overwrite '/usr/share/java/juh.jar', which is also in
package libjuh-java
forcemerge 947909 947907
thanks

Hi,

On Thu, Jan 02, 2020 at 12:32:24AM +0100, Domenico Cufalo wrote:
> Upgrading to v. 1:6.4.0~rc1-5, I had this output:

*After* a failed upgrade.

> Preparing to unpack .../ure_6.4.0~rc1-5_amd64.deb ...
> Unpacking ure (6.4.0~rc1-5) over (6.4.0~rc1-4) ...
> dpkg: error processing archive
> /var/cache/apt/archives/ure_6.4.0~rc1-5_amd64.deb
>  (--unpack):
>  trying to overwrite '/usr/share/java/juh.jar', which is also in package
> libjuh-
> java 1:6.4.0~rc1-5
> dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
> Errors were encountered while processing:
>  /var/cache/apt/archives/ure_6.4.0~rc1-5_amd64.deb
> E: Sub-process /usr/bin/dpkg returned an error code (1)

Yes, that is the real issue.

Regards,

Rene

Bug#947853: uninstallable due to wrong ure epoch in Breaks:

[Rene Engelhard]

Package: libjuh-java,libjurt-java,libridl-java,libunoloader-java
Version: 1:6.4.0~rc1-3
Severity: serious
Tags: pending

On Tue, Dec 31, 2019 at 12:54:16PM -0500, David Witbrodt wrote:
> It looks like you introduced some "Breaks" in 1:6.4.0~rc1-3 that were not
> present before, and now things like libjuh-java have a Breaks on
> ure (< 1:6.4.0~beta1-1).  The epoch "1" on ure is problematic:
> 
> # apt-cache policy libreoffice ure
> libreoffice:
>   Installed: 1:6.4.0~rc1-4
> [...]
> ure:
>   Installed: 6.4.0~rc1-4
> 
> As you can see, ure is versioned without the epoch, while libreoffice*.deb
> packages _are_ versioned with the epoch.

In addition to my reply on-list:

Making a proper bugreport out if this since ftp-master is currently
broken and a upload will take even if done now...

Will mark as reported by you once I have the number.

> PS:  if I have misdiagnosed anything above, sorry for the noise.  It looked
> to me like a versioning problem has been introduced, and (if that is so) I
> wanted to make you aware of it ASAP.

No, completely correct anaysis.

Regards,

Rene
> 

Re: Heads up: version 1:6.4.0~rc1-4 makes libreoffice-java-common uninstallable

[Rene Engelhard]

Hi,

On Tue, Dec 31, 2019 at 12:54:16PM -0500, David Witbrodt wrote:
> It looks like you introduced some "Breaks" in 1:6.4.0~rc1-3 that were not
> present before, and now things like libjuh-java have a Breaks on

Jup. See #947446.

> ure (< 1:6.4.0~beta1-1).  The epoch "1" on ure is problematic:
> 
> # apt-cache policy libreoffice ure
> libreoffice:
>   Installed: 1:6.4.0~rc1-4
> [...]
> ure:
>   Installed: 6.4.0~rc1-4
> 
> As you can see, ure is versioned without the epoch, while libreoffice*.deb
> packages _are_ versioned with the epoch.

*sigh*. Indeed.

Will upload a new version ASAP.

Regards,

Rene

Bug#947488: closed by r...@rene-engelhard.de (Re: Bug#947488: libreoffice-common: Error in /usr/share/doc-base/access2base', line 7: all `Format' sections are invalid.)

[Rene Engelhard]

Hi,

On Sun, Dec 29, 2019 at 04:56:00PM +, Thorsten Glaser wrote:
> found 947488 1:6.4.0~rc1-2
   
> >If this explanation is unsatisfactory and you have not received a
> >better one in a separate message then please contact r...@rene-engelhard.de 
> >by
> >replying to this email.
> 
> It’s not fixed, trivially:

Of course not when the fix (as I wrote) is in -3.

Regards,

Rene

Bug#947469: marked as done (Error in `/usr/share/doc-base/access2base', line 7: all `Format' sections are invalid.)

[Rene Engelhard]

reopen 947469
close 947469 1:6.4.0~rc1-3
thanks

Hi,

On Sun, Dec 29, 2019 at 05:03:04PM +, Debian Bug Tracking System wrote:
> Date: Sun, 29 Dec 2019 16:58:22 + (UTC)
> From: Thorsten Glaser 
> To: 947488-d...@bugs.debian.org
> cc: r...@rene-engelhard.de
> Subject: Bug#947488: marked as done (libreoffice-common: Error in
>  /usr/share/doc-base/access2base', line 7: all `Format' sections are
>  invalid.) (fwd)
> 
> Version: 1:6.4.0~rc1-3
> 
> Ah, well…

What on earth? You really believe I didn't fix it up myself after I
noticed the error and wrote about it?

Actually I directly forcedmerged with Michael Biebls bug.

Trying to fix the "Done:" up. What a waste of time.

Regards,

Rene

Bug#947612: Re : Bug#947612: libreoffice-writer: Can’t see the characters’ colour.

[Rene Engelhard]

On Sun, Dec 29, 2019 at 11:01:19AM +0100, nicolas.patr...@gmail.com wrote:
> I have this bug since a long time.

Since when? That should be recorded in Version:. Right now the BTS
thinks it's new in 6.4.0~rc1-3 since you specified that...

> Here are what I see in lo-w (no colour) and what I get when I export the file 
> in pdf (the colours are here as expected).

And I don*t get it either in 6.3.4-2~bpo10+1 on stable (gt3/GNOME)
nor in a testing...

That said, I *of course* only tested on amd64 and just happened to see

> Architecture: i386 (i686)

in your report. My bad, maybe it's 32bit only? 32bit builds are not done
upstream anymore and so they might miss stuff...

I should create a i386 VM I guess...

Any reason you stick to this (imho obsolete) architecture? Your PC
should be able to run amd64?


Regards,

Rene

Bug#947612: libreoffice-writer: Can’t see the characters’ colour.

[Rene Engelhard]

tag 947612 + unreproducible
tag 947612 + moreinfo
thanks

Hi,

On Sat, Dec 28, 2019 at 04:13:35PM +0100, Nicolas Patrois wrote:
> When I apply a colour, I don’t see it in the edit view (I only see black).
> I must open the preview to see them.

Works here. (gtk3/GNOME here, but I also tried in Plasma)

Regards,

Rene

P.S:
> Kernel: Linux 4.17.0-3-686-pae (SMP w/3 CPU cores)
> Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE

Maybe you should apply a sane configutration to your machine first? I
assume this module is "nvidia"...