Bug#916125: hunspell: "hunspell -D" does not print loaded dictionary

[Rene Engelhard]

forwarded 916125 https://github.com/hunspell/hunspell/issues/608
thanks

On Mon, Dec 10, 2018 at 12:31:44PM +0100, Itaï BEN YAACOV wrote:
> Commit 27829f0 which pplies to version 1.7.0 makes "hunspell -D" without 
> files quit early.
> Too early to print the loaded dictionary, making "hunspell -D" not perform as 
> expexted [...]

See https://github.com/hunspell/hunspell/issues/608

> and breaking eacs flyspell.

$ apt-file search flyspell
dictionaries-common:
/usr/share/dictionaries-common/site-elisp/flyspell.el
emacs-common: /usr/share/emacs/25.2/lisp/textmodes/flyspell.elc
emacs-el: /usr/share/emacs/25.2/lisp/textmodes/flyspell.el.gz
emacspeak:
/usr/share/emacs/site-lisp/emacspeak/lisp/emacspeak-flyspell.el
jed-extra: /usr/share/jed/jed-extra/drop-in/flyspell.sl
xemacs21-basesupport:
/usr/share/xemacs21/xemacs-packages/lisp/text-modes/flyspell.elc
xemacs21-basesupport-el:
/usr/share/xemacs21/xemacs-packages/lisp/text-modes/flyspell.el.gz

Erm, which one of these is the real(tm) one?

> Reverting the commit, or moving the leave logic a little later, solves this.

Or fixing emacs, see
https://github.com/hunspell/hunspell/issues/608#issuecomment-444955561 ff.

Regards,

Rene

Bug#913641: upstream bug

[rene . engelhard]

forwarded 913641 https://bugs.documentfoundation.org/show_bug.cgi?id=121925
thanks

This is (now also) https://bugs.documentfoundation.org/show_bug.cgi?id=121925
-- 
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.

Bug#915726: libreoffice: fails to build with poppler 0.71

[rene . engelhard]

Hi,

>Please apply the patches applied in Ubuntu to fix the libreoffice
>build with poppler 0.71. Debian may switch to poppler 0.71 before the
>Buster Transition Freeze.

Sure? Asked Emilio about it when I saw ..

>The first patch is
>https://cgit.freedesktop.org/libreoffice/core/commit/?id=5e8bdd92

... this. And he said "no" :)

Regards,

René

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

Bug#913069: python-uno is also mising in the transition page

[Rene Engelhard]

On Fri, Nov 30, 2018 at 02:06:07PM +0100, Eric Valette wrote:
> FYI : The build did succeed for several platform but unfortunately failed for 
> amd64 :-(

Yeah :(

Welcome to experimental ;-)

Builds fine on my system, though. I already did start a build
when you first posted it but then busy with other stuff/RL/unstable

I will upload my hand-build for now to get this fixed.

Yes, that is bad but this is experimental after all and we should get this 
tested
(even when this wouldn't be ready in time for buster which would be "squeezing 
it"
in anyway.)

Regards,

Rene

Bug#915019: Bug #915019 in libreoffice marked as pending

[Rene Engelhard]

Hi,

On Fri, Nov 30, 2018 at 05:27:32AM +0100, Andreas Beckmann wrote:
> On 2018-11-29 22:49, Rene Engelhard wrote:
> > https://salsa.debian.org/libreoffice-team/libreoffice/libreoffice/commit/e3b05379e04aa4d3d0756d351463182b5bfa2882
> 
> You want "1:6.2.0~beta1-2~" as the version in the maintscript, to act on
> upgrades from all buggy versions (including the 1:6.2.0~beta1-1+b1 (or
> later) binNMUs), too.

One *can* do that, but experimental is experimental and this is "only" a
transitional package

Regards,

Rene

Bug#914516: transition: hunspell

[Rene Engelhard]

block 914516 by 915060
thanks

Hi,

On Thu, Nov 29, 2018 at 10:17:49PM +0100, Rene Engelhard wrote:
> > Uploaded.
> 
> Installed everywhere (except ksd where it is only Built but not uploaded
> for hours), so you can schedule bin-NMUs.

Noticed link-grammar (though it builds) fails the autopkgtest of the
testing version because its test assumes stuff which isn't fullfilled.
See #915060 for my analysis

Regards,
  
Rene

Bug#915060: link-grammar: autopkgtest relies on built binaries without matching dependencies

[Rene Engelhard]

Source: link-grammar
Version: 5.5.0-1
Severity: serious

Hi,

$ cat debian/tests/control
Tests: unit-tests
Depends: @, python3-distutils, build-essential, hunspell-en-us, locales-all,
 default-jdk [!hppa !hurd-i386 !m68k !sh4],
Restrictions: build-needed

So far so good.

But that means that in the testing migration autopkgtests this breaks when
there is a hunspell transition.

See e.g. 
https://ci.debian.net/data/autopkgtest/testing/amd64/l/link-grammar/1399248/log.gz

What seems to happen (correct me if I am wrong) is:

1. link-grammar gets built. Because the autopkgtest injects libhunspell 1.7 
somehow into the
build this one is built against libhunspell-1.7.

2. Now the test packages get installed in a clean environment. Because you just 
say "@" you get
the dependencies from your own package (libhunspell-1.6) , not the built one 
(as should be, indeed)

3. The test now fails because it cannot open the libhunspell-1.7.so.0 because 
what was installed for
2. was just libhunspell-1.6.

Maybe you want to add at least @builddeps@? But that would only hide the 
problem...

Regards,

Rene

Bug#915019: libreoffice-mysql-connector: copyright file missing after upgrade (policy 12.5)

[Rene Engelhard]

On Thu, Nov 29, 2018 at 03:49:58PM +0100, Andreas Beckmann wrote:
> >From the attached log (scroll to the bottom...):
> 
> 0m50.5s ERROR: WARN: Inadequate results from running adequate!
>   libreoffice-mysql-connector: missing-copyright-file 
> /usr/share/doc/libreoffice-mysql-connector/copyright
> 
>   MISSING COPYRIGHT FILE: /usr/share/doc/libreoffice-mysql-connector/copyright
>   # ls -lad /usr/share/doc/libreoffice-mysql-connector
>   drwxr-xr-x 2 root root 40 Nov 21 08:16 
> /usr/share/doc/libreoffice-mysql-connector
>   # ls -la /usr/share/doc/libreoffice-mysql-connector/
>   total 0
>   drwxr-xr-x   2 root root   40 Nov 21 08:16 .
>   drwxr-xr-x 209 root root 4340 Nov 21 08:16 ..

*sigh*...

> It is recommended to use the dpkg-maintscript-helper commands
> 'dir_to_symlink' and 'symlink_to_dir' (available since dpkg 1.17.14)
> to perform the conversion, ideally using d/$PACKAGE.maintscript.

Will do.

> Do not forget to add 'Pre-Depends: ${misc:Pre-Depends}' in d/control.

Please update your template :)

dpkg   | 1.17.27   | oldstable  | source, amd64, arm64,
armel, armhf, i386, mips, mipsel, powerpc, ppc64el, s390x

dpkg 1.17.14 is a given.

Regards,

Rene

Bug#914516: transition: hunspell

[Rene Engelhard]

Hi,

On Wed, Nov 28, 2018 at 10:42:14PM +0100, Rene Engelhard wrote:
> On Wed, Nov 28, 2018 at 07:07:54PM +0100, Emilio Pozuelo Monfort wrote:
> > On 24/11/2018 11:07, Rene Engelhard wrote:
> > > Package: release.debian.org
> > > Severity: normal
> > > User: release.debian@packages.debian.org
> > > Usertags: transition
> > > 
> > > hunspell 1.7 was finally released. It includes a load of fixes
> > > we miss e.g. in LibreOffice because instead of using the
> > > patched-internal version we use the system version.
> > > 
> > > Cleared NEW just now.
> > > 
> > > So I'd like to get this transition done asap after
> > > icu/boost/python3.7-as-default is done :)
> > > 
> > > Did a rebuild using ratt and (almost) all packages built fine, except
> > > some otherwise failing packages (mudlet and plume-creator (both sid
> > > only) because of #907159 and #887534)
> > > I skipped firefox, too; firefox-esr is fine.
> > > (And libreoffice, but libreoffice is "of course" fine, too)
> > 
> > Go ahead.
> 
> Uploaded.

Installed everywhere (except ksd where it is only Built but not uploaded
for hours), so you can schedule bin-NMUs.

Regards,
 
Rene

Bug#914516: transition: hunspell

[Rene Engelhard]

Hi,

On Wed, Nov 28, 2018 at 07:07:54PM +0100, Emilio Pozuelo Monfort wrote:
> On 24/11/2018 11:07, Rene Engelhard wrote:
> > Package: release.debian.org
> > Severity: normal
> > User: release.debian@packages.debian.org
> > Usertags: transition
> > 
> > hunspell 1.7 was finally released. It includes a load of fixes
> > we miss e.g. in LibreOffice because instead of using the
> > patched-internal version we use the system version.
> > 
> > Cleared NEW just now.
> > 
> > So I'd like to get this transition done asap after
> > icu/boost/python3.7-as-default is done :)
> > 
> > Did a rebuild using ratt and (almost) all packages built fine, except
> > some otherwise failing packages (mudlet and plume-creator (both sid
> > only) because of #907159 and #887534)
> > I skipped firefox, too; firefox-esr is fine.
> > (And libreoffice, but libreoffice is "of course" fine, too)
> 
> Go ahead.

Uploaded.

Regards,

Rene

Bug#914619: "LibreOffice Still" should be used by the stable distribution

[Rene Engelhard]

Hi,

On Sun, Nov 25, 2018 at 07:28:43PM +0100, Rene Engelhard wrote:
> And no, if you mean we always should update to still: no. See
> e.g. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=820350

Oh, and let's assume we shipped "still" aka 6.0.x in stretch now.
Now we'd need to update to 6.1.x with it's new library etc. needs. And
the same with 6.1->6.2. As I said in the other bug: No, I believe
in stable distributions and integration and I consider the thingy done
with firefox a bug inflicted by the fact that browsers are "special"
and mozilla doesn't provide security patches - whereas I *do* get the
commits for LibreOffice and can/do backport those.

For new features  there's backports. (yes, you filed an other bug that
you don't like them, but...=

Regards,
 
Rene

Bug#914619: "LibreOffice Still" should be used by the stable distribution

[Rene Engelhard]

notfound 914619 1:6.1.3-1
severity 914619 wishlist
forcemerge 820350 914619
thanks

On Sun, Nov 25, 2018 at 07:09:22PM +0100, 21na...@gmail.com wrote:
> For example when "Debian Buster" will be the stable distribution,
> "LibreOffice Still" should be used.

When buster will be released 6.1.x *will* be "Still". Buster will
only freeze next year.
6.0.x which is the current still is basically EOL. EOL tomorrow.

And no, if you mean we always should update to still: no. See
e.g. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=820350

Regards,

Rene

Bug#914516: transition: hunspell

[Rene Engelhard]

Hi,
On Sat, Nov 24, 2018 at 11:07:25AM +0100, Rene Engelhard wrote:
> Did a rebuild using ratt and (almost) all packages built fine, except
> some otherwise failing packages (mudlet and plume-creator (both sid
> only) because of #907159 and #887534)

Sorry, missed one: aegisub (also sid-only): #873327

Regards,
 
Rene

Bug#914516: transition: hunspell

[Rene Engelhard]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition

hunspell 1.7 was finally released. It includes a load of fixes
we miss e.g. in LibreOffice because instead of using the
patched-internal version we use the system version.

Cleared NEW just now.

So I'd like to get this transition done asap after
icu/boost/python3.7-as-default is done :)

Did a rebuild using ratt and (almost) all packages built fine, except
some otherwise failing packages (mudlet and plume-creator (both sid
only) because of #907159 and #887534)
I skipped firefox, too; firefox-esr is fine.
(And libreoffice, but libreoffice is "of course" fine, too)

Ben file:

title = "hunspell";
is_affected = .depends ~ "libhunspell-1.6-0" | .depends ~ "libhunspell-1.7-0";
is_good = .depends ~ "libhunspell-1.7-0";
is_bad = .depends ~ "libhunspell-1.6-0";

(or auto-hunspell)

Regards,

Rene

Bug#912140: libreoffice-base,libreoffice-common: trying to overwrite '/usr/lib/libreoffice/share/basic/dialog.xlc', which is also in package libreoffice-{base,common} 1:5.2.7-1+deb9u3

[Rene Engelhard]

On Sun, Nov 18, 2018 at 07:11:03PM +0100, Rene Engelhard wrote:
> But so we can remove --package $DPKG_MAINTSCRIPT_PACKAGE without a risk 
> anyway:
> dpkg   | 1.16.18   | oldoldstable   | source, amd64, armel, 
> armhf, i386, ia64, kfreebsd-amd64, kfreebsd-i386, mips, mipsel, powerpc, 
> s390, s390x, sparc
> (or at least it wouldn't be worse than before.)

Done for in git (for sid, whevever this gets uploaded):
https://salsa.debian.org/libreoffice-team/libreoffice/libreoffice/commit/45af0362e3471c52783a0a6a4b5b384a32d013ce

Regards,
  
Rene

Bug#912140: libreoffice-base,libreoffice-common: trying to overwrite '/usr/lib/libreoffice/share/basic/dialog.xlc', which is also in package libreoffice-{base,common} 1:5.2.7-1+deb9u3

[Rene Engelhard]

Hi again,

On Sun, Nov 18, 2018 at 01:54:20PM +0100, Rene Engelhard wrote:
> 
>dpkg-divert --package $DPKG_MAINTSCRIPT_PACKAGE --add --rename \
> 
> is the call. So indeed, if $DPKG_MAINTSCRIPT_PACKAGE was empty... Now
> Good point.
> the question is why that happens Now the question is why that happens...

While looking for DPKG_MAINTSCRIPT_PACKAGE in dpkgs changelog I saw

dpkg (1.16.0) unstable; urgency=low

  [ Guillem Jover ]
  * Use DPKG_MAINTSCRIPT_PACKAGE environment variable as package name on
dpkg-divert when no --package or --local options have been specified.
[...]

That doesn't explain why it wasn't set... TTBOMK dpkg sets it?

  Internal environment
[...]
   DPKG_MAINTSCRIPT_PACKAGE
  Defined by dpkg on the maintainer script environment to the 
(non-arch-qualified) package name being handled (since dpkg 1.14.17).
[...]

(man dpkg)

But so we can remove --package $DPKG_MAINTSCRIPT_PACKAGE without a risk anyway:
dpkg   | 1.16.18   | oldoldstable   | source, amd64, armel, armhf, 
i386, ia64, kfreebsd-amd64, kfreebsd-i386, mips, mipsel, powerpc, s390, s390x, 
sparc
(or at least it wouldn't be worse than before.)
or even write the package name out, as we know it...

Now that means we just need to fix eventually broken configurations "-add", 
though
I am not sure we should even attempt to do it in maintainer scripts and not let 
the
local admin do it.

Regards,
 
Rene

Bug#912140: libreoffice-base,libreoffice-common: trying to overwrite '/usr/lib/libreoffice/share/basic/dialog.xlc', which is also in package libreoffice-{base,common} 1:5.2.7-1+deb9u3

[Rene Engelhard]

Hi,

On Mon, Oct 29, 2018 at 02:00:37PM +0100, Axel Beckert wrote:
> Axel Beckert wrote:
> > When trying to fix this manually using "dpkg --purge --force-depends"
> > to later use "apt install -f", libreoffice-base failed to purge due to
> > some (seemingly broken) diversion. Here's my next try after
> > libreoffice-common was already successfully purged:
> > 
> > root@localhost:~# dpkg --purge --force-depends libreoffice-base 
> >   
> > dpkg: libreoffice-base: dependency problems, but removing anyway as you 
> > requested:
> >  libreoffice-report-builder-bin depends on libreoffice-base.
> >  libreoffice depends on libreoffice-base.
> > 
> > (Reading database ... 63690 files and directories currently installed.)
> > Removing libreoffice-base (1:5.2.7-1+deb9u4) ...
> > dpkg-divert: error: mismatch on package
> >   when removing 'diversion of /usr/lib/libreoffice/share/basic/dialog.xlc 
> > to /usr/lib/libreoffice/share/basic/dialog.xlc.noaccess by libreoffice-base'
> >   found 'diversion of /usr/lib/libreoffice/share/basic/dialog.xlc to 
> > /usr/lib/libreoffice/share/basic/dialog.xlc.noaccess by --add'
> 
> Please note the "--add" in here.
> 
> In /var/lib/dpkg/diversions, the according entry had "--add" listed as
> package name. I fixed the issue by replacing "--add" with
> "libreoffice-base" and then the package could be purged.
> 
> So if there never was a dpkg-divert call in the libreoffice maintainer
> scripts that was so broken that "--add" had been parsed as package
> name, feel free to close this as locally misconfigured system. (I
> though can imagine that by e.g. missing quotes around a shell
> variable, this could happen if the variable with the package name was
> empty for some reason.

Good point.

   dpkg-divert --package $DPKG_MAINTSCRIPT_PACKAGE --add --rename \

is the call. So indeed, if $DPKG_MAINTSCRIPT_PACKAGE was empty... Now
the question is why that happens Now the question is why that happens...

Regards,

Rene

Bug#913360: libreoffice-base-drivers: please switch to libmariadb-java

[Rene Engelhard]

Hi,

On Fri, Nov 16, 2018 at 08:17:06PM +0100, Markus Koschany wrote:
> > But I think this will give us problems if we suggest libmariadb-java and 
> > don't get the
> > new class into this...
> > 
> > Can't we get some symlinks in libmariadb-java? :)
> 
> I'm not sure if I understand you correctly. The classname
> "org.mariadb.jdbc.Driver" can't be changed because this path is
> hardcoded in mariadb-java-client.jar. We could create a symlink to
> mysql-connector-java.jar but that wouldn't achieve anything. So this is

Hmm, true.

Ah, well, then the .NEWS then.

Regards,

Rene

Bug#913360: libreoffice-base-drivers: please switch to libmariadb-java

[Rene Engelhard]

Hi,

On Fri, Nov 09, 2018 at 11:45:41PM +0100, Rene Engelhard wrote:
> > diff --git a/connectivity/qa/complex/connectivity/JdbcLongVarCharTest.java 
> > b/connectivity/qa/complex/connectivity/JdbcLongVarCharTest.java
> > index a44f1b9d1..03a8293ef 100644
> > --- a/connectivity/qa/complex/connectivity/JdbcLongVarCharTest.java
> > +++ b/connectivity/qa/complex/connectivity/JdbcLongVarCharTest.java
> > @@ -59,7 +59,7 @@ public class JdbcLongVarCharTest extends ComplexTestCase
> >  
> >  String url = "jdbc:mysql://localhost:3306/mysql?user=root";
> >  com.sun.star.beans.PropertyValue prop[] = new PropertyValue[1];
> > -prop[0] = new PropertyValue("JavaDriverClass", 0, 
> > "com.mysql.jdbc.Driver", PropertyState.DIRECT_VALUE);
> > +prop[0] = new PropertyValue("JavaDriverClass", 0, 
> > "org.mariadb.jdbc.Driver", PropertyState.DIRECT_VALUE);
> 
> Not used, ttbomk. At least we have no test environment where this ever
> could work. No MySQL running.

OK, this is not used because of

--- snip ---
ifneq ($(filter QADEVOOO,$(BUILD_TYPE)),)
$(eval $(call gb_Module_add_subsequentcheck_targets,connectivity,\
Jar_ConnectivityTools \
))
# FIXME: Does not work. Convert to JUnit.
# JunitTest_complex \

endif
--- snip ---

> > diff --git 
> > a/connectivity/registry/mysql/org/openoffice/Office/DataAccess/Drivers.xcu 
> > b/connectivity/registry/mysql/org/openoffice/Office/DataAccess/Drivers.xcu
> > index 77988448f..acd8bfdaf 100644
> > --- 
> > a/connectivity/registry/mysql/org/openoffice/Office/DataAccess/Drivers.xcu
> > +++ 
> > b/connectivity/registry/mysql/org/openoffice/Office/DataAccess/Drivers.xcu
> > @@ -33,7 +33,7 @@
> >  
> >  
> >
> > -com.mysql.jdbc.Driver
> > +org.mariadb.jdbc.Driver
> >
> >  
> >  
> > diff --git a/connectivity/source/drivers/mysql/YDriver.cxx 
> > b/connectivity/source/drivers/mysql/YDriver.cxx
> > index 95094265e..c0ad7802e 100644
> > --- a/connectivity/source/drivers/mysql/YDriver.cxx
> > +++ b/connectivity/source/drivers/mysql/YDriver.cxx
> > @@ -54,7 +54,7 @@ namespace connectivity
> >  css::uno::Sequence const & info)
> >  {
> >  return comphelper::NamedValueCollection(info).getOrDefault(
> > -"JavaDriverClass", OUString("com.mysql.jdbc.Driver"));
> > +"JavaDriverClass", OUString("org.mariadb.jdbc.Driver"));
> >  }
> >  }
> >  
> > @@ -185,7 +185,7 @@ namespace connectivity
> >  aProps.push_back( PropertyValue(
> >"JavaDriverClass"
> >,0
> > -  
> > ,makeAny(OUString("com.mysql.jdbc.Driver"))
> > +  
> > ,makeAny(OUString("org.mariadb.jdbc.Driver"))
> >,PropertyState_DIRECT_VALUE) );
> >  }
> >  }

But I think this will give us problems if we suggest libmariadb-java and don't 
get the
new class into this...

Can't we get some symlinks in libmariadb-java? :)

Did

diff --git a/changelog b/changelog
index fe843d07..bdb4d3dd 100644
--- a/changelog
+++ b/changelog
@@ -7,13 +7,17 @@ libreoffice (1:6.1.3-2) UNRELEASED; urgency=medium
 -Djdk.net.URLClassPath.disableClassPathURLCheck=true to JAVAIFLAGS;
 see https://gerrit.libreoffice.org/#/c/63118/2
 
+  * debian/patches/use-mariadb-java-instead-of-mysql-java.diff: as name says;
+use org.mariadb.jdbc.Driver instead of com.mysql.jdbc.Driver
   * debian/control.in:
-- Add libmariadb-java as new alternative before libmysql-java in
-  -base-drivers' Suggests: See #912916 for more information.
+- Suggest libmariadb-java instead of libmysql-java. See #912916 for more
+  information.
   * debian/patches/jdbc-driver-classpaths.diff: add org.mariadb.jdbc.Driver
-classpath to /usr/share/java/mariadb-java-client.jar
+classpath pointing to /usr/share/java/mariadb-java-client.jar
   * debian/libreoffice-base.bug-script.in: add libmariadb-java
-  (closes: #913360)
+  (closes: #913360, thanks Markus Koschany)
+
+  * debian/libreoffice-base-drivers.NEWS: add NEWS about above change
 
  -- Rene Engelhard   Fri, 09 Nov 2018 20:59:58 +0100
 
diff --git a/control b/control
index bb17ab05..635b538c 100644
--- a/control
+++ b/control
@@ -795,7 +795,7 @@ Depends: libreoffice-core, ${misc:Depends}, 
${shlibs:D

Bug#904316: Fwd: boost-defaults_1.67.0.1_multi.changes is NEW

[Rene Engelhard]

Hi,

On Thu, Nov 15, 2018 at 05:59:03PM +0100, Rene Engelhard wrote:
> On Mon, 23 Jul 2018 10:26:34 +0100 you wrote: 
> 

On Thu, Nov 01, 2018 at 11:13:16PM + actually, sorry, my bad.

> So obviously not. You could at least have uploaded a matching boost-defaults
> to experimental to clear NEW *before* you claim the transition was ready for
> months (which it wasn't.)

Still true.

Regards,
 
Rene

Bug#904316: Fwd: boost-defaults_1.67.0.1_multi.changes is NEW

[Rene Engelhard]

Hi,

Huh?

On Thu, Nov 15, 2018 at 03:03:35PM +, Dimitri John Ledkov wrote:
> -- Forwarded message -
> From: Debian FTP Masters 
> Date: Thu, 15 Nov 2018 at 14:40
> Subject: boost-defaults_1.67.0.1_multi.changes is NEW
> To: Dimitri John Ledkov , Debian Boost Team
> 
> 
> 
> binary:libboost-container-dev is NEW.
> binary:libboost-contract-dev is NEW.
> binary:libboost-numpy-dev is NEW.
> binary:libboost-stacktrace-dev is NEW.
> binary:libboost-numpy-dev is NEW.
> binary:libboost-contract-dev is NEW.
> binary:libboost-container-dev is NEW.
> binary:libboost-stacktrace-dev is NEW.
[...]

On Mon, 23 Jul 2018 10:26:34 +0100 you wrote:   
  

--- snip ---
This transition was ready to be started for just over three months now. 





May I upload boost-defaults to start the transition to boost1.67?   

 snip ---

So obviously not. You could at least have uploaded a matching boost-defaults
to experimental to clear NEW *before* you claim the transition was ready for
months (which it wasn't.)

Regards,

Rene

Bug#913762: RFP: jbibtex -- Java BibTeX API

[Rene Engelhard]

Package: wnpp
Severity: wishlist

* Package name: jbibtex
  Version : 1.0.17
  Upstream Author : villu.ruusm...@gmail.com
* URL : https://github.com/jbibtex/jbibtex
* License : BSD
  Programming Lang: Java
  Description : Java BibTeX API

Java BibTeX and LaTeX parser and formatter library

I tried to package this myself but failed using mh_make since
some test(-only) dependencies were not found and I couldn't get past
it (and get the tests disabled?)

So if someone wanted to package it I'd be very grateful as writer2latex
1.6.x needs it (upstream "of course" embeds the binary jar :/))

Regards,

Rene

Bug#913702: libwpd: CVE-2018-19208

[Rene Engelhard]

Hi,

On Wed, Nov 14, 2018 at 08:19:05AM +0100, Salvatore Bonaccorso wrote:
> [2] 
> https://src.fedoraproject.org/rpms/libwpd/blob/e42834b844f3282d8ccb0889abf1b33f3f71e02f/f/0001-Resolves-rhbz-1643752-bounds-check-m_currentTable-ac.patch

Will apply, thanks.

> Please adjust the affected versions in the BTS as needed.

Assuming stable was affected, I assume it's the same as last time and
this should go over p-u and not -security (since "only" DOS)?

Regards,

Rene

Bug#911925: Bug#913641: libreoffice-report-builder: report builder reports fail to run

[Rene Engelhard]

On Tue, Nov 13, 2018 at 06:40:06PM -0800, Anton Cohen wrote:
>On Tue, 13 Nov 2018 13:13:09 +0100 Lionel Elie Mamane
><[1]lio...@mamane.lu> wrote:
>> Downgrading to 8u171-b11-2 makes this problem disappear.
>Except 8u171-b11-2 (and all 8u171 builds) was removed from the pool for
>stretch today.

Yeah.

>It is very broken that stretch doesn't have any working Java package in
>apt repos (except in openjdk-11 in stretch-backports).
>I realize this isn't a libreoffice package issue, but it seems
>like #911925 is being ignored.

There was a longish IRC discussion yesterday, it simply boils down to
backporting the follow-up commit they did for 11 also to the 8 package
which has only the initial fix.

Trying to fix this via stable-proposed-updates in LibreOffice could
theoretically be possible but it would be a big change in every jar
LibreOffice ships and also then sit in proposed-updates until whenever
the next stable update is. Thus I think openjdk should get a regression
update via -security.
But that's in the realm of the security team and the openjdk
maintainers, not mine...

Regards,

Rene

Bug#912916: mysql-connector-java: CVE-2018-3258: allows low privileged attacker to compromise it

[Rene Engelhard]

Hi,

On Mon, Nov 05, 2018 at 04:54:55PM +0100, Markus Koschany wrote:
>   libreoffice-base-drivers

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

Regards,

Rene

Bug#913360: libreoffice-base-drivers: please switch to libmariadb-java

[Rene Engelhard]

Hi,

Ah, bad timing for my own effort when I saw the other uploads... :)
Did a commit just adding it as an alternative...

On Fri, Nov 09, 2018 at 11:13:22PM +0100, Markus Koschany wrote:
> The 0001 patch can be applied for the Debian packaging.

How is this going to help on stretch where libmysql-java is still there
and libmariadb-java doesn't exist? Or people who use it on buster/sid
and didn't install libmariadb-java?

That's why I added the alternative only in my attempt...

> be applied against the upstream sources. We have to replace the old
> MySQL driver class with the new one from MariaDB. Except for that
> libmariadb-java should just work.

Hmm.

> diff --git a/connectivity/qa/complex/connectivity/JdbcLongVarCharTest.java 
> b/connectivity/qa/complex/connectivity/JdbcLongVarCharTest.java
> index a44f1b9d1..03a8293ef 100644
> --- a/connectivity/qa/complex/connectivity/JdbcLongVarCharTest.java
> +++ b/connectivity/qa/complex/connectivity/JdbcLongVarCharTest.java
> @@ -59,7 +59,7 @@ public class JdbcLongVarCharTest extends ComplexTestCase
>  
>  String url = "jdbc:mysql://localhost:3306/mysql?user=root";
>  com.sun.star.beans.PropertyValue prop[] = new PropertyValue[1];
> -prop[0] = new PropertyValue("JavaDriverClass", 0, 
> "com.mysql.jdbc.Driver", PropertyState.DIRECT_VALUE);
> +prop[0] = new PropertyValue("JavaDriverClass", 0, 
> "org.mariadb.jdbc.Driver", PropertyState.DIRECT_VALUE);

Not used, ttbomk. At least we have no test environment where this ever
could work. No MySQL running.

> diff --git 
> a/connectivity/registry/mysql/org/openoffice/Office/DataAccess/Drivers.xcu 
> b/connectivity/registry/mysql/org/openoffice/Office/DataAccess/Drivers.xcu
> index 77988448f..acd8bfdaf 100644
> --- a/connectivity/registry/mysql/org/openoffice/Office/DataAccess/Drivers.xcu
> +++ b/connectivity/registry/mysql/org/openoffice/Office/DataAccess/Drivers.xcu
> @@ -33,7 +33,7 @@
>  
>  
>
> -com.mysql.jdbc.Driver
> +org.mariadb.jdbc.Driver
>
>  
>  
> diff --git a/connectivity/source/drivers/mysql/YDriver.cxx 
> b/connectivity/source/drivers/mysql/YDriver.cxx
> index 95094265e..c0ad7802e 100644
> --- a/connectivity/source/drivers/mysql/YDriver.cxx
> +++ b/connectivity/source/drivers/mysql/YDriver.cxx
> @@ -54,7 +54,7 @@ namespace connectivity
>  css::uno::Sequence const & info)
>  {
>  return comphelper::NamedValueCollection(info).getOrDefault(
> -"JavaDriverClass", OUString("com.mysql.jdbc.Driver"));
> +"JavaDriverClass", OUString("org.mariadb.jdbc.Driver"));
>  }
>  }
>  
> @@ -185,7 +185,7 @@ namespace connectivity
>  aProps.push_back( PropertyValue(
>"JavaDriverClass"
>,0
> -  
> ,makeAny(OUString("com.mysql.jdbc.Driver"))
> +  
> ,makeAny(OUString("org.mariadb.jdbc.Driver"))
>,PropertyState_DIRECT_VALUE) );
>  }
>  }

Didn't know it was there hardcoded in some places, I only knew about the
file touched by jdbc-driver-classpaths.diff

But see above.

Regards,

Rene

Bug#905437: libreoffice-common: AppArmor denies access to mesa shader cache

[Rene Engelhard]

Hi,

On Thu, Nov 08, 2018 at 07:18:02PM +0200, Vincas Dargis wrote:
> We have now mesa abstraction in Buster that fixes this bug...

So >= 2.13 as for dri-enumerate? I don't see something specific in the
Debian changelog?

> but so what? I
> guess I'll have to add yet another [0] backport to upstream profile because
> it exists not only for Buster...
> 
> I am thinking to propose LibreOffice upstream to split profile into
> apparmor-x.yz directories to match policies against particular AppArmor
> release. In this case, apparmor-2.13/program.soffice.bin would have
> `#include `, meanwhile apparmor-2.12 (how many? maybe one
> apparmor-legacy?) would have inline backport..?

I'd say this is the only viable solution if one wanted to avoid
gazillions of backports

Regards,

Rene

Bug#911925:

[rene . engelhard]

retitle 911925 S8195874: Improve jar specification adherence breaks reverse 
depends build and runtime
clone 911925 -1
reassign -1 openjdk-10-jdk
found -1 10.0.2+13-2
thanks

OpenJDK 10 is affected as well.
-- 
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.

Bug#911925: Bug#913641: libreoffice-report-builder: report builder reports fail to run

[rene . engelhard]

block 913641 by 911925
affects 911925 libreoffice-report-builder
thanks

>>Not clear if you are saying I need to do it, or you need to do it. I
>>don't quite understand the issue, you do, so I assume you will, you
>>will be able to explain to the Java package maintainers the issue?
>
>I will do, yes.
>
>>Please CC me, I'd like to be educated on that.
>
>The Gerrit discussion explains it..openjdk doesn't honour some
>classpath specifications anymore so stuff is simply not found.

Ah, there is already 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=911925#29 etc.

For #911925 readers: LibreOffice with it's (relative) Class-Path: entries is 
affected as well, breaking build and runtime...

Regards,

René


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

Bug#913641: libreoffice-report-builder: report builder reports fail to run

[rene . engelhard]

tag 913641 - moreinfo
retitle 913641 libreoffice-report-builder: report builder reports fail to run 
after S8195874 in OpenJDK
thanks

Am 13. November 2018 13:13:09 MEZ schrieb Lionel Elie Mamane :
>On Tue, Nov 13, 2018 at 12:58:02PM +0100, rene.engelh...@mailbox.org
>wrote:
>> Am 13. November 2018 12:13:52 MEZ schrieb Lionel Elie Mamane
>:
>>> Package: libreoffice-report-builder
>>> Version: 1:6.1.3-1
>>> Severity: normal
>
>> Huh, what? On a stable? Seriousl
>
>Yes, I'm dogfooding more recent version of LibreOffice. Seriously,
>that's how one gets early testers and bug reports before release.

Use testing or sid. Or use the backport. Installing sid packages per se on 
stable is broken.

>>> Trying to run any report (a report builder one, not a legacy one)
>>> fails with error message:
>
>>> Can not activate the factory for
>>>
>org.libreoffice.report.pentaho.SOReportJobFactory$_SOReportJobFactory
>
>> I assume it's related to stables openjdk 8 update and the discussion
>> in https://gerrit.libreoffice.org/63118.
>
>Hmmm... Switching LibreOffice to use OpenJDK 7 solves that issue. I
>guess this confirms your assumption?

Yes.

>> Need to file a bug on openjdk...
>
>Not clear if you are saying I need to do it, or you need to do it. I
>don't quite understand the issue, you do, so I assume you will, you
>will be able to explain to the Java package maintainers the issue?

I will do, yes.

>Please CC me, I'd like to be educated on that.

The Gerrit discussion explains it..openjdk doesn't honour some classpath 
specifications anymore so stuff is simply not found.

>>> ii  openjdk-8-jre [java6-runtime]  8u181-b13-2~deb9u1
>
>> This is probably the cause What happens with the old openjdk 8 on
>> stretch or openjdk 11.0.1+13?
>
>Downgrading to 8u171-b11-2 makes this problem disappear.

Ok, that also confirms it...

Regards,

René

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

Bug#913641: libreoffice-report-builder: report builder reports fail to run

[rene . engelhard]

notfound 913641 1:6.1.3-1
found 1:5.2.7-1+deb9u4
severity 913641 grave
tag 913641 + moreinfo
thanks

Am 13. November 2018 12:13:52 MEZ schrieb Lionel Elie Mamane :
>Package: libreoffice-report-builder
>Version: 1:6.1.3-1
>Severity: normal

Huh, what? On a stable? Seriousl

>Trying to run any report (a report builder one, not a legacy one)
>fails with error message:
>
>Can not activate the factory for
>org.libreoffice.report.pentaho.SOReportJobFactory$_SOReportJobFactory
>
>Nothing particular on stderr.

I assume it's related to stables openjdk 8 update and the discussion in 
https://gerrit.libreoffice.org/63118.

Doesn't affect sid or buster with jdk 11 (which is default there.. )

Need to file a bug on openjdk...

>-- System Information:
>Debian Release: 9.6
>  APT prefers stable-updates
>APT policy: (600, 'stable-updates'), (600, 'stable'), (400, 'testing'),
>(300, 'unstable'), (1, 'experimental')
>Architecture: amd64 (x86_64)
>Foreign Architectures: i386
> [...]
>Versions of packages libreoffice-report-builder depends on:
>ii  libbase-java   1.1.6-2
>ii  libcommons-logging-java1.2-1
>ii  libflute-java  1:1.1.6-3
>ii  libfonts-java  1.1.6.dfsg-3
>ii  libformula-java1.1.7.dfsg-2
>ii  liblayout-java 0.2.10-2
>ii  libloader-java 1.1.6.dfsg-4
>ii  libpentaho-reporting-flow-engine-java  0.9.4-4
>ii  libreoffice-common 1:6.1.3-1
>ii  libreoffice-core   1:6.1.3-1
>ii  libreoffice-java-common1:6.1.3-1
>ii  libreoffice-report-builder-bin 1:6.1.3-1
>ii  librepository-java 1.1.6-3
>ii  libsac-java1.3+dfsg-2
>ii  libserializer-java 1.1.6-4
>ii  libxml-java1.1.6.dfsg-3

This honestly is Soo broken. Ok, the backport will have the same problem 
(that's why I needed +2 there) but..

>ii  openjdk-8-jre [java6-runtime]  8u181-b13-2~deb9u1

This is probably the cause What happens with the old openjdk 8 on stretch or 
openjdk 11.0.1+13?

Regards

Rene

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

Bug#913051: hsqldb1.8.0 FTBFS with OpenJDK 11

[rene . engelhard]

Am 6. November 2018 12:54:10 MEZ schrieb Adrian Bunk :
>Source: hsqldb1.8.0
>Version: 1.8.0.10+dfsg-9
>Severity: serious
>Tags: ftbfs
>
>https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/hsqldb1.8.0.html
>
>...
>lib:
>[javac] /build/1st/hsqldb1.8.0-1.8.0.10+dfsg/build/build.xml:351:
>warning: 'includeantruntime' was not set, defaulting to
>build.sysclasspath=last; set to false for repeatable builds
>[javac] Compiling 40 source files to
>/build/1st/hsqldb1.8.0-1.8.0.10+dfsg/classes
>[javac] Using ant.build.javac.target 1.5 is no longer supported,
>switching to 6
>[javac] Using ant.build.javac.target 1.5 is no longer supported,
>switching to 6
>[javac] Using ant.build.javac.source 1.5 is no longer supported,
>switching to 6
>[javac] warning: [options] bootstrap class path not set in conjunction
>with -source 6
>[javac] warning: [options] source value 6 is obsolete and will be
>removed in a future release
>[javac] warning: [options] target value 1.6 is obsolete and will be
>removed in a future release
>[javac] warning: [options] To suppress warnings about obsolete options,
>use -Xlint:-options.
>[javac]
>/build/1st/hsqldb1.8.0-1.8.0.10+dfsg/src/org/hsqldb/lib/java/JavaSystem.java:163:
>error: cannot find symbol
>[javac] System.runFinalizersOnExit(true);
>[javac]   ^
>[javac]   symbol:   method runFinalizersOnExit(boolean)
>[javac]   location: class System
>[javac] Note: Some input files use or override a deprecated API.
>[javac] Note: Recompile with -Xlint:deprecation for details.
>[javac] Note: Some input files use unchecked or unsafe operations.
>[javac] Note: Recompile with -Xlint:unchecked for details.
>[javac] 1 error
>[javac] 4 warnings

Hi,

sigh, ok. Thankfully this only means copying
https://cgit.freedesktop.org/libreoffice/core/commit/external/hsqldb/patches/hsqldb-runFinalizersOnExit.patch?id=1d3f2ed0606cc971513dab5932ec7d1dd2a15f90
 ...

Regards

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

Bug#912016: liborcus: Please package the tools

[Rene Engelhard]

On Sun, Oct 28, 2018 at 06:25:25PM +0100, Rene Engelhard wrote:
> > Can you please consider packaging these tools?
> 
> And have 1 month waiting time in NEW? :(
> Had that with libetonyek lately...

Uploaded (as said, will be in NEW)

Regards,
 
Rene

Bug#912140: libreoffice-base,libreoffice-common: trying to overwrite '/usr/lib/libreoffice/share/basic/dialog.xlc', which is also in package libreoffice-{base,common} 1:5.2.7-1+deb9u3

[Rene Engelhard]

Hi,

On Sun, Oct 28, 2018 at 03:44:59PM +0100, Axel Beckert wrote:
> root@localhost:~# dpkg --purge --force-depends libreoffice-base   
> 
> dpkg: libreoffice-base: dependency problems, but removing anyway as you 
> requested:
>  libreoffice-report-builder-bin depends on libreoffice-base.
>  libreoffice depends on libreoffice-base.
> 
> (Reading database ... 63690 files and directories currently installed.)
> Removing libreoffice-base (1:5.2.7-1+deb9u4) ...
> dpkg-divert: error: mismatch on package
>   when removing 'diversion of /usr/lib/libreoffice/share/basic/dialog.xlc to 
> /usr/lib/libreoffice/share/basic/dialog.xlc.noaccess by libreoffice-base'
>   found 'diversion of /usr/lib/libreoffice/share/basic/dialog.xlc to 
> /usr/lib/libreoffice/share/basic/dialog.xlc.noaccess by --add'
> dpkg: error processing package libreoffice-base (--purge):
>  subprocess installed post-removal script returned error exit status 2
> Processing triggers for desktop-file-utils (0.23-1) ...
> Processing triggers for mime-support (3.60) ...
> Processing triggers for man-db (2.7.6.1-2) ...
> Errors were encountered while processing:
>  libreoffice-base
> 
> So if that diversion isn't coming from the package, feel free to close
> this bug report.

Is is, but see my other reply...

Regards,

Rene

Bug#912016: liborcus: Please package the tools

[Rene Engelhard]

Hi,

On Sat, Oct 27, 2018 at 11:07:32AM +0200, Alex Hermann wrote:
> By default, a number of tools are build that can be used to convert
> spreadsheets between different formats:

IMHO the tool to convert spreadsheets between different formats here is
called LibreOffice (or unoconv or something else for that matter - which
uses orcus) :).

> Can you please consider packaging these tools?

And have 1 month waiting time in NEW? :(
Had that with libetonyek lately...

Regards,

Rene

Bug#912140: libreoffice-base,libreoffice-common: trying to overwrite '/usr/lib/libreoffice/share/basic/dialog.xlc', which is also in package libreoffice-{base,common} 1:5.2.7-1+deb9u3

[Rene Engelhard]

On Sun, Oct 28, 2018 at 02:08:13PM +, Axel Beckert wrote:
> Package: libreoffice-base,libreoffice-common
> Version: 1:5.2.7-1+deb9u4
> Severity: serious
> Justification: file conflict, fails to upgrade

No.

> When upgrading Debian Stretch on a friends Gemini PDA (arm64), parts of 
> libreoffice failed to 
> upgrade from deb8u3 to deb8u4 due a file conflict between two of its binary 
> packages.
> 
> It looks as if dialog.xlc moved between packages between deb8u3 and deb8u4 on 
> at least arm64.

No, it didn't.

As you say already in your other mail this is a diversion. If your
system was clean before there was no issue (there was a short time where
the diversion was broken, yes...

-base diverts dialog.xlc (and others) because I don't see the need on
forcing Access2Base macros (yes, doing what it says...) on everyone.

This is basically the case since ages:

libreoffice (1:4.3.0~rc3-2) experimental; urgency=low

  * Brown paper bag release

  * debian/patches/handle-symlinks-to-icon-themes-correctly.diff: as name says;
from upstream

  * debian/rules:
- fix typo so export DISABLE_CVE_TESTS=TRUE is actually set
- add symlinks for images*.zip again
- s/iceweasel-dev/npapi-sdk-dev/. Re-enable system-npapi-headers
- ENABLE_AVAHI=n (closes: #749770, #755309)
  * debian/libreoffice-base.preinst.in: fix version check (closes: #755290)
  * debian/libreoffice-base.postrm.in: add more checks for the
Access2Base diversions; add forgotten recommended abort-upgrade step
from policy manual

 -- Rene Engelhard   Sat, 19 Jul 2014 09:57:19 +0200
[...]
libreoffice (1:4.3.0~beta1-1) experimental; urgency=low

  * new upstream beta release
- fixes unconditional execution of VBA macros (CVE-2014-0247)

  * debian/patches/odk-no-dot.diff: HAVE_DOT=NO in Doxyfiles to prevent loads
of error: " Problems running dot: exit code=127, command='dot'" 
  * debian/patches/disable-ftp-nohost-test.diff: remove, seems to work now

  * debian/rules:
- move /usr/lib/libreoffice/share/basic/Access2Base from -common to -base, 
  as it clearly is Base-specific
  * debian/control.in:
- add Replaces: for the Access2Base move
  * debian/libreoffice-base.{preinst,postrm}.in: dpkg-divert dialog.xlc
and script.xlc... FIXME: Better, scalable solution..
  * debian/control.help.in:
- make -help-* depend on -style-default (closes: #748434)

 -- Rene Engelhard   Fri, 23 May 2014 07:31:12 +0200

And those didn't change since then.

Regards,

Rene

Bug#911897: AppArmor "complain" for oosplash & soffice

[Rene Engelhard]

Hi,

On Fri, Oct 26, 2018 at 01:24:52PM -0400, Anthony DeRobertis wrote:
> Which one you get depends on the exact way the app is launched. In the
> screenshot, the xterm on the left was launched as part of session restore;
> the one on the right was launched from the KDE menu (bottom-left thingy).
> The same thing happens on my normal desktop. I normally launch my xterms via
> a KDE hotkey, those get the /tmp one. (And normally I start libreoffice from
> an xterm). That could explain how it was missed — launch it from the menu
> instead, and it'll be given ~/.Xauthority.

Ah... And I "of course" launched konsole from the menu...
(Alt-F2, konsole gives the same.)

> I'm not sure what the intended behavior is here; the current behavior of
> using both files is surely a bug in KDE. Seems perfectly reasonable to
> reassign to them.

Hmm.

Regards,

Rene

Bug#911897: AppArmor "complain" for oosplash & soffice

[Rene Engelhard]

clone 911897 -1
retitle 911897 apparmor denies /tmp/xauth-1000-_0 set by sddm/KDE
retitle -1 please include nvidia apparmor abstraction to allow nvidia
driver resources
severity -1 wishlist
tag -1 - unreproducible
tag -1 - moreinfo
tag -1 + wontfix
thanks

On Fri, Oct 26, 2018 at 12:13:00PM -0400, Anthony DeRobertis wrote:
> On 10/26/18 11:26 AM, Rene Engelhard wrote:
> > > Then there is a lot of nVidia stuff, probably from this machine using the 
> > > nVidia proprietary
> > > driver.
> > Then the nvidia drivers (which I do not care about at all, to be honest)
> > or libdrm or whatever should ship needed stuff. I mean, it's not LO using
> > the stuff directly, it's those. It would imho be completely nonsense to
> > make LO honour driver-specific things for every possible driver.
> 
> apparmor ships an /etc/apparmor.d/abstractions/nvidia — but AFAICT each app
> needs to #include it, which I agree is rather silly. E.g., Thunderbird and
> Totem both include it.

Making a bug out of this for documentation purposes. Wontfix, though.

Regards,

Rene

Bug#911897: AppArmor "complain" for oosplash & soffice

[Rene Engelhard]

On Fri, Oct 26, 2018 at 12:13:00PM -0400, Anthony DeRobertis wrote:
> On 10/26/18 11:26 AM, Rene Engelhard wrote:
> > > Then there is a lot of nVidia stuff, probably from this machine using the 
> > > nVidia proprietary
> > > driver.
> > Then the nvidia drivers (which I do not care about at all, to be honest)
> > or libdrm or whatever should ship needed stuff. I mean, it's not LO using
> > the stuff directly, it's those. It would imho be completely nonsense to
> > make LO honour driver-specific things for every possible driver.
> 
> apparmor ships an /etc/apparmor.d/abstractions/nvidia — but AFAICT each app
> needs to #include it, which I agree is rather silly.

Yes, it is.

I think the worst which can happen (I at least hope..) is no acceleration or 
OpenGL
features (I consider LO using OpenGL for some stuff a nuisance anyway, but some
stuff of it got disabled upstream anyway.

> PS: Just saw your other reply about $XAUTHORITY, and yeah, that's how it's
> set here. Definitely KDE launched from sddm:
> 
>  1473 ?Ssl0:00 /usr/bin/sddm
>  1707 tty7 Ssl+  90:32  \_ /usr/lib/xorg/Xorg -nolisten tcp -auth 
> /var/run/sddm/{592354bf-2439-40b4-9616-3bd3943e9502} -background none 
> -noreset -displayfd 17 -seat seat0 vt7
> 11894 ?S  0:00  \_ /usr/lib/x86_64-linux-gnu/sddm/sddm-helper 
> --socket /tmp/sddm-authe60db6a4-a442-404f-9833-9762d7da6686 --id 1 --start 
> /usr/bin/startkde --user anthony
> 11897 ?S  0:00  \_ /bin/sh /usr/bin/startkde
> 11960 ?Ss 0:00  \_ /usr/bin/ssh-agent env 
> LD_PRELOAD=libgtk3-nocsd.so.0 /usr/bin/startkde
> 12010 ?S  0:00  \_ kwrapper5 /usr/bin/ksmserver
> 
> ... going to try to figure out why my machine is different than yours.

Here it was just apt install sddm kde-plasma-desktop. (don't use
KDE myself.)

Regards,

Rene

Bug#911897: AppArmor "complain" for oosplash & soffice

[Rene Engelhard]

Hi,

On Fri, Oct 26, 2018 at 05:26:56PM +0200, Rene Engelhard wrote:
> > Then there is a lot of nVidia stuff, probably from this machine using the 
> > nVidia proprietary
> > driver.
> 
> Then the nvidia drivers (which I do not care about at all, to be honest)
> or libdrm or whatever should ship needed stuff. I mean, it's not LO using
> the stuff directly, it's those. It would imho be completely nonsense to
> make LO honour driver-specific things for every possible driver.
> 
> I think I saw these once in an other report where I reassigned that one
> or a clone to either of those, need to search for it...

Ah, no, I just closed it it seems based on what the real issue in that
bug was:

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

Regards,
 
Rene

Bug#911897: AppArmor "complain" for oosplash & soffice

[Rene Engelhard]

tag 911897 + moreinfo
tag 911897 + unreproducible
thanks

On Thu, Oct 25, 2018 at 05:49:27PM -0400, Anthony DeRobertis wrote:
> Presumably the xauth one will effect a lot of people (as that's the
> value of $XAUTHORITY here, set by KDE/sddm). Then there is a lot of

Really?

$ echo $XAUTHORITY
/home/rene/.Xauthority

(set by sddm logging into GNOME)

Shouldn't - if KDE set it - it not have been found when Vincas did
https://cgit.freedesktop.org/libreoffice/core/commit/?id=c86e4ad53391d17d1eb54845b5999889f7e65061
?

$ echo $XAUTHORITY
/home/rene/.Xauthority

(set by sddm logging into Plasma)

> Oct 25 16:52:11 Zia kernel: audit: type=1400 audit(1540500731.877:200): 
> apparmor="ALLOWED" operation="open" profile="libreoffice-oopslash" 
> name="/tmp/xauth-1000-_0" pid=25385 comm="oosplash" requested_mask="r" 
> denied_mask="r" fsuid=1000 ouid=1000
   ^^

root@frodo:~# aa-enforce /etc/apparmor.d/usr.lib.libreoffice.program.oosplash 
Setting /etc/apparmor.d/usr.lib.libreoffice.program.oosplash to enforce
mode.
root@frodo:~# aa-enforce /etc/apparmor.d/usr.lib.libreoffice.program.soffice.bin
Setting /etc/apparmor.d/usr.lib.libreoffice.program.soffice.bin to
enforce mode.

Starts fine and does NOT print above (or deny) it.

Regards,

Rene

Bug#911897: AppArmor "complain" for oosplash & soffice

[Rene Engelhard]

Hi,

On Thu, Oct 25, 2018 at 05:49:27PM -0400, Anthony DeRobertis wrote:
> I understand the goal is to get AppArmor back in to enforcing mode
> someday, so presumably these complain-mode allow messages are of use.
> Presumably the xauth one will effect a lot of people (as that's the
> value of $XAUTHORITY here, set by KDE/sddm).

Maybe.

> Then there is a lot of nVidia stuff, probably from this machine using the 
> nVidia proprietary
> driver.

Then the nvidia drivers (which I do not care about at all, to be honest)
or libdrm or whatever should ship needed stuff. I mean, it's not LO using
the stuff directly, it's those. It would imho be completely nonsense to
make LO honour driver-specific things for every possible driver.

I think I saw these once in an other report where I reassigned that one
or a clone to either of those, need to search for it...

> (Side note, I understand sandboxing web browsers and the like with
> AppArmor. Firefox shouldn't have random access to $HOME. But I wonder if
> its really worth it for LibreOffice; by its nature it must have access
> to my important documents. But that's a discussion for elsewhere, I'm
> sure.)

Yes, and there's the "get xyz from the filesystem" or "do not run xyz
after a security bug was used" scenario.

I wouldn't have written a profile if one (incomplete and ooold, as noticed.) 
wasn't
already there and ready to be installed.

> Installed VCLplugs:
> 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
> +++----=
> un  libreoffice-gtk2   (no description available)
> un  libreoffice-gtk3   (no description available)
> un  libreoffice-kde(no description available)

Not that it matters here, but no -kde(5) even when you're using KDE?

Regards,

Rene

Bug#910905: libreoffice: soffice.bin --headless launched from unoconv/odt2txt memory bomb / not terminating

[Rene Engelhard]

tag 910905 + moreinfo
thanks

On Sat, Oct 13, 2018 at 10:27:44AM +0200, Marcel Partap wrote:
> My ranger curses file manager invokes `odt2txt --stdout` (which would be a 
> good

Out of odt2txt or out of unoconv?

$ apt-file search odt2txt
firejail-profiles: /etc/firejail/odt2txt.profile
odt2txt: /usr/bin/odt2txt.odt2txt
odt2txt: /usr/lib/mime/packages/odt2txt
odt2txt: /usr/share/doc/odt2txt/README.Debian
odt2txt: /usr/share/doc/odt2txt/changelog.Debian.amd64.gz
odt2txt: /usr/share/doc/odt2txt/changelog.Debian.gz
odt2txt: /usr/share/doc/odt2txt/copyright
odt2txt: /usr/share/man/man1/odt2txt.odt2txt.1.gz
unoconv: /usr/bin/odt2txt.unoconv
unoconv: /usr/share/man/man1/odt2txt.unoconv.1.gz

Your subject suggests the latter, but...

> default for odt2txt by the way) for document previews. The `soffice.bin
> --headless` (haha still *office binary lol) seems to be a server process that

Backwards-compatibility. Yeah, don't like it either :-)

> does not automatically exit.

I think it does when you do --convert-to. Otherwise I think the program
using LO needs to take care of this...

>  Occasionally it has hit some thing where it would consume all my memory
> (24GB+24GB swap).
> Is there some way to limit the maximum memory this process shall eat via some
> systemd / cgroups / ulimit conf?

Yes, most probably? Not a bug here, though?

> Timing out the server would also be a good idea in my opinion. Wouldn't it?

There's no "server" here. You are running a "normal" LibreOffice. (in
headless mode).

--listen= etc. would be "server" mode if you wish. But I think unoconv
does this?

Regards,

Rene

Bug#910576: libreoffice-base: in my form, all entries are "input required"

[Rene Engelhard]

forwarded 910576 https://bugs.documentfoundation.org/show_bug.cgi?id=120245
tag 910576 + upstream
tag 910576 + fixed-upstream
thanks

Hi,

On Mon, Oct 08, 2018 at 11:04:37AM +0200, Martin Lutz wrote:
> since the last update of libreoffice-base, all entries in my form are
> suddenly "input required". When saving my changes I get the error message
> "Error writing to database. Input required in field 'fieldname'. Please enter 
> a
> value".
> 
> In the corresponding table, all fields are still on the status "input 
> required"
> --> no. Saving an entry with empty fields is not a problem, there.
> 
> The database is mysql which is running on a different computer.

This sounds like
https://bugs.documentfoundation.org/show_bug.cgi?id=120353 which is
marked as duplicate of
https://bugs.documentfoundation.org/show_bug.cgi?id=120245 which is
fixed in git for 6.1.3 (and 6.2.0).

Regards,

Rene

Bug#910601: libreoffice-common: Sometimes X11 crash when opened.

[Rene Engelhard]

tag 910601 + moreinfo
tag 910601 + unreproducible
thanks

Hi,

On Mon, Oct 08, 2018 at 05:15:28PM +0200, Nicola wrote:
> Package: libreoffice-common
> Version: 1:6.1.2-1
> Severity: normal
> 
> Dear Maintainer,
> 
> Sometimes X11 crash.

If you do what? Specific action? Randomly? Why a LibreOffice bug?
Which graphic driver?

> [18266.049204] kauditd_printk_skb: 19 callbacks suppressed
> [18266.049204] audit: type=1400 audit(1539010923.604:47): apparmor="ALLOWED" 
> operation="open" profile="libreoffice-soffice" 
> name="/home/nicola/.cache/mesa_shader_cache/index" pid=6859 
> comm="soffice.bin" requested_mask="wrc" denied_mask="wrc" fsuid=1000 ouid=1000
> [18266.142172] audit: type=1400 audit(1539010923.696:48): apparmor="ALLOWED" 
> operation="mknod" profile="libreoffice-soffice" 
> name="/usr/local/share/fonts/.uuid.TMP-1K2Yod" pid=6858 comm="soffice.bin" 
> requested_mask="c" denied_mask="c" fsuid=1000 ouid=1000
> [18266.142247] audit: type=1400 audit(1539010923.696:49): apparmor="ALLOWED" 
> operation="mknod" profile="libreoffice-soffice" 
> name="/usr/share/fonts/cMap/.uuid.TMP-J6rugr" pid=6858 comm="soffice.bin" 
> requested_mask="c" denied_mask="c" fsuid=1000 ouid=1000
> [18266.142809] audit: type=1400 audit(1539010923.696:50): apparmor="ALLOWED" 
> operation="mknod" profile="libreoffice-soffice" 
> name="/usr/share/fonts/X11/util/.uuid.TMP-iXd47E" pid=6858 comm="soffice.bin" 
> requested_mask="c" denied_mask="c" fsuid=1000 ouid=1000
> [18266.142811] audit: type=1400 audit(1539010923.696:51): apparmor="ALLOWED" 
> operation="mknod" profile="libreoffice-soffice" 
> name="/usr/share/poppler/cMap/Adobe-CNS1/.uuid.TMP-2ifEZS" pid=6858 
> comm="soffice.bin" requested_mask="c" denied_mask="c" fsuid=1000 ouid=1000
> [18266.142880] audit: type=1400 audit(1539010923.696:52): apparmor="ALLOWED" 
> operation="mknod" profile="libreoffice-soffice" 
> name="/usr/share/poppler/cMap/Adobe-GB1/.uuid.TMP-mMpeR6" pid=6858 
> comm="soffice.bin" requested_mask="c" denied_mask="c" fsuid=1000 ouid=1000
> [18266.142882] audit: type=1400 audit(1539010923.696:53): apparmor="ALLOWED" 
> operation="mknod" profile="libreoffice-soffice" 
> name="/usr/share/poppler/cMap/Adobe-Japan1/.uuid.TMP-JhNOIk" pid=6858 
> comm="soffice.bin" requested_mask="c" denied_mask="c" fsuid=1000 ouid=1000
> [18266.142883] audit: type=1400 audit(1539010923.696:54): apparmor="ALLOWED" 
> operation="mknod" profile="libreoffice-soffice" 
> name="/usr/share/poppler/cMap/Adobe-Japan2/.uuid.TMP-XMkpAy" pid=6858 
> comm="soffice.bin" requested_mask="c" denied_mask="c" fsuid=1000 ouid=1000
> [18266.142930] audit: type=1400 audit(1539010923.696:55): apparmor="ALLOWED" 
> operation="mknod" profile="libreoffice-soffice" 
> name="/usr/share/poppler/cMap/Adobe-Korea1/.uuid.TMP-IM6ZrM" pid=6858 
> comm="soffice.bin" requested_mask="c" denied_mask="c" fsuid=1000 ouid=1000
> [18266.142931] audit: type=1400 audit(1539010923.696:56): apparmor="ALLOWED" 
> operation="mknod" profile="libreoffice-soffice" 
> name="/usr/share/fonts/opentype/ipafont-gothic/.uuid.TMP-1C3Aj0" pid=6858 
> comm="soffice.bin" requested_mask="c" denied_mask="c" fsuid=1000 ouid=1000
> [18268.987056] nouveau :01:00.0: bus: MMIO read of  FAULT at 
> 619444 [ IBUS ]


... so you want to say that this has to do with apparmor? Don't believe
so, but the last entries definitely are fonts and for poppler, so are
you trying to open some PDF?

Sorry, as of now this bug report isn't anything one can act on. Not me,
and not upstream.

Regards,

Rene

Bug#909577: hunspell-bg: Upgrade to fix encoding problem

[Rene Engelhard]

tag 909577 + moreinfo
thanks

Hi,

On Tue, Sep 25, 2018 at 04:33:40PM +0200, Pander wrote:
> Please, upgrade in order to fix an encoding problem, the incorrect
> encoding name was used. This has been fixed upstream.

And you are reporting this against 5.2.5 which is in stable. Of course
this fix didn't end up there since it it isn't critical. Or is it?

> See also:
> https://sourceforge.net/p/bgoffice/bugs/6/
> https://bugs.documentfoundation.org/show_bug.cgi?id=117392

That was abandoned? Because "UTF-8 works now".

So what is the actual, still existing (in 6.1.1/.2) problem?

Regards,

Rene

Bug#909504: libreoffice-draw: Error when saving odg file containing curve

[Rene Engelhard]

forwarded 909504 https://bugs.documentfoundation.org/show_bug.cgi?id=118313
tag 909504 + moreinfo
thanks

On Mon, Sep 24, 2018 at 05:37:54PM +0200, H. wrote:
> Package: libreoffice-draw
> Version: 1:6.1.1-1
> Severity: important
> 
> When trying to save a draw document containing just a curve I got the 
> following
> error message:
> "Error saving the document : Write Error. The file could not be 
> written."
> 
> Steps to Reproduce:
> 1. Create a straight line (document can still be saved)
> 2. Click on the line, enable the Points tools (F8), click on one end point of
> the line
> 3. Click "Convert to Curve" --> saving the document fails
> 
> I tried this on multiple machines running Testing (including fresh installs)
> over several weeks and could reproduce the bug also with version 5.4.7.2 from
> libreoffice.org. According to my older bug report
> (https://bugs.documentfoundation.org/show_bug.cgi?id=118313) Arch Linux 
> doesn't
> seem to be affected, thus this might be a Debian-related problem.

Which contradicts that it doesn't work with "5.4.7.2 from libreoffice.org".
How can it be a Debian-related (in libreoffice package, this is where
you are reporting at) problem if it also breaKS with libreoffice.org
packages? (Comparing 5.4.x to 6.1 is comparing apple and pies, though.)

Regards,

Rene

Bug#908981: libetonyek: Please package tools

[Rene Engelhard]

Hi,

On Mon, Sep 17, 2018 at 11:34:08AM +1200, Olly Betts wrote:
> There's even an unused libetonyek-tools.install, though the contents
> seem to have just been copied from the libvisio packaging:
> 
> https://sources.debian.org/src/libetonyek/0.1.8-1/debian/libetonyek-tools.install/

Indeed. Fixed.

> Please add a libetonyek-tools binary package which includes these
> command line tools.

Given that needs NEW it's not very likely I am doing it without needing
NEW anyway for an other reason...

Regards,

Rene

Bug#909152: libreoffice: Google Drive file listing fails with "General input/output error"

[Rene Engelhard]

found 909152 1:6.1.1~rc1-2
thanks

Hi,

On Wed, Sep 19, 2018 at 02:31:21AM +, Stephen Paul Weber wrote:
> This has previously been reported to upstream:
> https://bugs.documentfoundation.org/show_bug.cgi?id=117271 but in fact
> it works in upstream's version so they closed it and suggested reporting
> to Ubuntu, which was done:
> https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/1754400 and
> it seems they found a fix for their version:
> 
> > after we explicitly enabled the google drive API for the project that
> > holds the API key used in libreoffice (it was not enabled previously)
> 
> > From this I infer that distribution packages of libreoffice are using
> their own Google API credentials different from those of upstream, and

Of course, that's at least nominally a secret. And upstream doesn't give us this
secret (then it de-facto wouldn't be secret anymore given it has to be
in the source package somewhere to use it.)

> that an option needs to be enabled on these credentials to allow Google
> Drive access.

Hmm. Maybe.

CC'ing the chromium maintainers (where we get the id/"secret" from) -
- from /etc/chromium.d/apikeys...
Can you check whether said option is enabled for the id/"secret"?

Regards,

Rene

Bug#908523: libcppunit-dev: cppunit.m4 is no more provided

[Rene Engelhard]

severity 908523 minor
retitle 908523 /usr/share/doc/libcppunit-dev/README.Debian contains 
documentation about removed AM_PATH_CPPUNIT()
thanks

Hi,

On Mon, Sep 10, 2018 at 09:10:09PM +0200, Ludovic Rousseau wrote:
> But /usr/share/doc/libcppunit-dev/README.Debian contains a documentation
> of the M4 macro AM_PATH_CPPUNIT()

Remains from old days probably.

> Another strange thing is that /usr/share/aclocal/cppunit.m4 is listed as
> provided by libcppunit-dev from unstable by 
> https://packages.debian.org/search?searchon=contents=cppunit.m4=filename=unstable=any

packages.debian.orgs file contents are grossly outdated. No news.

> I could not find a replacement for cppunit.m4 in 
> https://www.gnu.org/software/autoconf-archive/The-Macros.html#The-Macros

pkg-config.

> If upstream decided to remove cppunit.m4, which looks to be the case,
> then maybe you should remove the file
> /usr/share/doc/libcppunit-dev/README.Debian

Which would make this a minor bug only, as it's only documentation.

> I also note that cppunit-config was also removed. Using cppunit.m4 from the 
> Debian stable does not work without cppunit-config.

True. Use pkg-config (PKG_CHECK_MODULES or however it's called)

> I suggest to:
> - remove README.Debian or, at least, change its content.
> - add a line in changelog that cppunit-config and cppunit.m4 have been 
> removed upstream and are no more provided

In a change which happened months ago? No.

Besides that, it's called evolution and replacing it with something
standard. Other *-config removals didn't end up promimently either; this
is _developer_ material anyway.

(If at all, NEWS, and that one would bother too many people imho.)

Regards,

Rene

Bug#908513: libreoffice - missing gallery when Dmaths is installed

[Rene Engelhard]

tag 908513 + moreinfo
thanks

On Mon, Sep 10, 2018 at 07:05:55PM +0200, Hans-J. Ullrich wrote:
> I think there is a litttle issue with the gallery in libreoffice.

Why in LibreOffice?

> If the libreoffice-dmaths package is installed, then I can gent no access to 
> the libreoffice-gallery. 
> (Clicking on the "Gallery"-icon showes me the dmaths gallery).
> 
> When libreoffice-dmaths is uninstralled, then the gallery (all pictures and 
> so on) are appearng again.
> I looked into the settings of libreoffice and searched at Google and others, 
> but could not find a solution,
> how to set the gallery-path to the "normal" gallery withj installed dmaths.
> 
> I believe, this is a bug. If I am wrong, please point me to the right 
> settings.

But that sounds like a dmaths bug? Maybe it needs to be adapted to LO
6.1?
I at least see many oor:op="replace" in dmaths? Maybe it is replacing
too much of LOs orginal gallery "config"?

dmaths is a separate extension.
CC'ing the dmaths maintainer.

Regards,

Rene

Bug#908237: libnumbertext-tools: "spellout" is not in $PATH and looks for data in the wrong places

[Rene Engelhard]

tag 908237 - moreinfo
tag 908237 - unreproducible
clone 908237 -1 -2
severity -1 wishlist
tag -1 + wontfix
tag -1 - pending
severity -2 normal
tag -2 - pending
retitle -2 should not search for data files in .
severity 908237 grave
forwarded 908237 https://github.com/Numbertext/libnumbertext/pull/36
thanks

Hi,

On Fri, Sep 07, 2018 at 05:47:54PM +0100, Stephane Chazelas wrote:
> $ dpkg -L libnumbertext-tools
> [...]
> /usr/lib/libnumbertext/spellout
> 
> The tool is meant to be invoked by the end user, but is not
> located in a directory in $PATH. I would expect it to go in
> /usr/bin (and have a corresponding man page in
> /usr/share/man/man1).

Let's handle this in an other bug.

> It looks first in "en.sor" in the current directory, which is a
> security vulnerability (for instance when run in /tmp where some
> attacker could have planted a malicious "en.sor" file).

Let's handle this in an other bug.

> And then in "/usr/share/numbertext" while "libnumbertext-data"
> installs those files in "/usr/share/libnumbertext" instead.

Fixed in git. (This bug :))

Next time, please use the principle to report one bug in one bug, not
multiple things in one bug...

Regards,

Rene

Bug#908237: libnumbertext-tools: "spellout" is not in $PATH and looks for data in the wrong places

[Rene Engelhard]

Hi,

On Sat, Sep 08, 2018 at 12:09:18AM +0100, Stephane Chazelas wrote:
> https://sources.debian.org/src/libnumbertext/1.0-2/debian/libnumbertext-data.install/
> putting data files in usr/share/libnumbertext while

Which installs how it is installed by "make install" by upstream, and
thus probably what the library (and users of that library - LibreOffice) 
expects.

See also libnumbertext.pc:

prefix=/usr
exec_prefix=${prefix}
libdir=${prefix}/lib/x86_64-linux-gnu
includedir=${prefix}/include
datarootdir=${prefix}/share
datadir=${datarootdir}
pkgdatadir=${datarootdir}/libnumbertext

Name: libnumbertext
Description: Library implementing Soros based Number to Number Name
conversion
Version: 1.0.3
Requires:
Libs: -L${libdir} -lnumbertext-1.0
Cflags: -I${includedir}/libnumbertext/

> https://sources.debian.org/src/libnumbertext/1.0-2/src/spellout.cxx/#L13
> expects them /usr/share/numbertext

I guess we should fix *this*.

Regards,

Rene

Bug#908237: libnumbertext-tools: "spellout" is not in $PATH and looks for data in the wrong places

[Rene Engelhard]

Hi,

On Fri, Sep 07, 2018 at 11:44:08PM +0200, Rene Engelhard wrote:
> On Fri, Sep 07, 2018 at 05:47:54PM +0100, Stephane Chazelas wrote:
> > The tool is meant to be invoked by the end user, but is not
> > located in a directory in $PATH. I would expect it to go in
> > /usr/bin (and have a corresponding man page in
> > /usr/share/man/man1).

Ah, now I remember why it's not in /usr/bin. I found "spellout" to be
too generic for /usr/bin: "Spellout what? Where? On the console? in
what form? Spell out some thingy over audio for blind people? Something
else?" 

(And upstream doesn't have a manpage.)

Regards,
 
Rene

Bug#908237: libnumbertext-tools: "spellout" is not in $PATH and looks for data in the wrong places

[Rene Engelhard]

Hi,

On Sat, Sep 08, 2018 at 12:09:18AM +0100, Stephane Chazelas wrote:
> I suppose the test tests at build time,

No, I said *autopkgtest*, which runs in the installed system. And see
the executed command.

> (and may be why the tool also looks in a "data" subdirectory of the current
> directory as there's one such directory in the source tree), so doesn't try
> and look for the data file in their final destination (/usr/share/numbertext
> != /usr/share/libnumbertext).

But yeah, that sounds like it (when they are run you are inside the
build tree afaicr).

Regards,

Rene

Bug#908237: libnumbertext-tools: "spellout" is not in $PATH and looks for data in the wrong places

[Rene Engelhard]

tag 908237 + moreinfo
tag 908237 + unreproducible
thanks

Hi,

On Fri, Sep 07, 2018 at 11:44:08PM +0200, Rene Engelhard wrote:
> > Also:
> > 
> > $ /usr/lib/libnumbertext/spellout -l en 101
> > spellout: missing language module
> [...]
> 
> I don't buy this: The autopkgtest of exactly the version you report it
> against:
> 
> autopkgtest [16:42:00]: test command1: if [
> "`/usr/lib/libnumbertext/spellout -l en 123`" != "one hundred
> twenty-three" ]; then echo "Invalid spellout of 123 for en." >&2; exit
> 1; else exit 0; fi
> autopkgtest [16:42:00]: test command1: [---
> autopkgtest [16:42:01]: test command1: ---]
> autopkgtest [16:42:01]: test command1:  - - - - - - - - - - results - -
> - - - - - - - -
> command1 PASS
> 
> I've no idea what you did, but you apparently did it wrong.

$ sudo chroot /data/pbuilder/build/sid /usr/lib/libnumbertext/spellout
-l en 123
[sudo] Passwort für rene: 
spellout: missing language module

Hmm. Interesting.

Regards,
 
Rene

Bug#908237: libnumbertext-tools: "spellout" is not in $PATH and looks for data in the wrong places

[Rene Engelhard]

tag 908237 + moreinfo
tag 908237 + unreproducible
thanks

Hi,

On Fri, Sep 07, 2018 at 05:47:54PM +0100, Stephane Chazelas wrote:
> The tool is meant to be invoked by the end user, but is not
> located in a directory in $PATH. I would expect it to go in
> /usr/bin (and have a corresponding man page in
> /usr/share/man/man1).

Fair point,

> Also:
> 
> $ /usr/lib/libnumbertext/spellout -l en 101
> spellout: missing language module
[...]

I don't buy this: The autopkgtest of exactly the version you report it
against:

autopkgtest [16:42:00]: test command1: if [
"`/usr/lib/libnumbertext/spellout -l en 123`" != "one hundred
twenty-three" ]; then echo "Invalid spellout of 123 for en." >&2; exit
1; else exit 0; fi
autopkgtest [16:42:00]: test command1: [---
autopkgtest [16:42:01]: test command1: ---]
autopkgtest [16:42:01]: test command1:  - - - - - - - - - - results - -
- - - - - - - -
command1 PASS

I've no idea what you did, but you apparently did it wrong.

Regards,

Rene

Bug#907710: libreoffice-report-builder: libre office base report builder labels are not working

[Rene Engelhard]

forwarded 907710 https://bugs.documentfoundation.org/show_bug.cgi?id=119067
tag 907710 + upstream
tag 907710 + moreinfo
thanks

Hi,

On Fri, Aug 31, 2018 at 01:34:58PM -0500, william l-k wrote:
> I was running some reports today and noticed that all of the labels in all of
> my reports were labeled "label". I was annoyed that I would have to fix this.
> 
> I went into a report in edit mode and fixed all of the labels. I then saved 
> the
> report and reran. The labels were not fixed. I tried this process with a 
> couple
> of the reports I run, all of which are having this bug.
> 
> I've taken a few screenshots to show whats going on.

That looks like https://bugs.documentfoundation.org/show_bug.cgi?id=119067 to 
me?

The "fix" mentioned there was also backported to the 6.1 branches and appears 
in 6.1.1 rc1
onwards.

Regards,

Rene

Bug#907650: /usr/lib/libreoffice/program/libmergedlo.so: undefined symbol: _ZN8MsLangId13getScriptTypeEN4o3tl10strong_intIt15LanguageTypeTagEE"

[Rene Engelhard]

reassign 907650 libreoffice-core
severity 907650 serious
tag 907650 + pending
thanks

Hi,

On Thu, Aug 30, 2018 at 07:42:45PM +0200, Davide Prina wrote:
> This bug has been archived has 864690, but this bug is present in testing if
> you upgrade libreoffice or part of it and not the whole system.

Yeah, I noticed that too when force-installing 6.1.1rc1 over 6.1.0-1
(which was in testing at that time).

Interesting that it's the same function. The same reason it can't be
(ttbomk), the function was and still is there.

> Please consider to upgrade the dependencies of all libreoffice packages to
> ure and uno-libs3 with the last version present in testing (6.1.1~rc1-1).

Jup, will make -core depend on ure (>= 6.1.1~)

Regards,

Rene

Bug#907476: libreoffice: file permissions are changed to 0600 when re-saving

[Rene Engelhard]

tag 907476 + upstream
tag 907476 + fixed-upstream
forwarded 907476 https://bugs.documentfoundation.org/show_bug.cgi?id=119050
thanks

Hi,

On Tue, Aug 28, 2018 at 02:25:03PM +0200, Brice Goglin wrote:
> When I create a document (tried with localc and lowriter), the output
> file is created with mode 0644 (as expected from my umask 022). However,
> whenever I open such a file and save it again, it is changed to 0600.
> 
> Same issue with 6.1.1~rc1-1 from unstable and 6.1.0-1 from testing.
> I think this issue didn't exist a couple months ago, hence I'd say
> it appeared with the upgrading to LO 6, but I can't easily verify.

Sounds like https://bugs.documentfoundation.org/show_bug.cgi?id=119050;
confirmed by upstream on IRC.

Regards,

Rene

Bug#905431: libreoffice-common: LibreOffice fails to print text unless "PDF as standard print job format" is chosen

[Rene Engelhard]

Hi,

On Sat, Aug 04, 2018 at 09:41:04PM +0100, Andrew Rule wrote:
>Just checked, and it appears that print option "PDF as standard print job
>format" is a standard setting, so I imagine you have to go into settings
>to turn it off.

Indeed.

That said there is also http://bugs.debian.org/906726, which was also
filed as https://bugs.documentfoundation.org/show_bug.cgi?id=119357.
Which is fixed in 6.1.1 rc1 (and that one is in unstable).

Does it work with 6.1.1 rc1?

Regards,

Rene

Bug#906726: libreoffice printing bug

[Rene Engelhard]

Hi,

On Mon, Aug 20, 2018 at 09:47:04AM +0100, Mark van Rossum wrote:
> I reported the bug at:
> https://bugs.documentfoundation.org/show_bug.cgi?id=119357

That one says:

--- snip ---
Commit Notification 2018-08-23 12:54:59 UTC
Jan-Marek Glogowski committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=4a58fd0e81b0375c71f6182233f0ec9390942cd1

tdf#119357 add the glyph, if the lookup failed

It will be available in 6.2.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 25 Commit Notification 2018-08-23 14:40:40 UTC
Jan-Marek Glogowski committed a patch related to this issue.
It has been pushed to "libreoffice-6-1":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=8d49069887443c9eeac9c52441ad1a183d12c384=libreoffice-6-1

tdf#119357 add the glyph, if the lookup failed

It will be available in 6.1.1.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 26 dxt.tfg 2018-08-23 16:27:27 UTC
I can confirm that the daily build of 6.1.1 dev fixed this issue (tested
on Mx Linux 17.1 and Linux Mint 18.3), and an another issue seen in
6.0.6 version that accented characters are printed as square characters.
Comment 27 Xisco Faulí 2018-08-27 15:13:10 UTC
(In reply to dxt.tfg from comment #26)
> I can confirm that the daily build of 6.1.1 dev fixed this issue
> (tested on
> Mx Linux 17.1 and Linux Mint 18.3), and an another issue seen in 6.0.6
> version that accented characters are printed as square characters.


Thanks for checking it in LibreOffice 6.1.1.
Setting to VERIFIED FIXED
--- snip ---

said commit is in 1:6.1.1~rc1-1 - so is in unstable. Can you confirm
it works?

Regards,

Rene

Bug#907397: libreoffice: writer crashes when trying to insert more fields

[Rene Engelhard]

Hi,

On Mon, Aug 27, 2018 at 04:45:34PM +0200, Olivier Tilloy wrote:
> Steps to reproduce:
>  1) Launch libreoffice-writer
>  2) Click on the "Insert" menu, then "Field" > "More Fields…"
> 
> Expected result: a dialog to select the type and contents of the field is
> shown.
> Current result: libreoffice crashes instantly.
> 
> I found that installing libreoffice-base-drivers makes the crash go away. The

So maybe we should recommend it then?

> one library from that package that seems to be required is libdbahsqllo.so.

Hmm, that sounds like a bug anyways...

>From my memory and from git log this is I think that file is the hsqldb binary 
>importer?

[...]
commit 60ac7418747530a006894a7941c67c5006d6158c
Author: Tamas Bunth 
Date:   Wed Feb 28 21:40:06 2018 +0100

HSQLDB Binary import

C++ implementation of reading HSQL's binary file format. This file
contains the actual rows for the tables, represented in an AVL tree.

Import starts from HsqlImporter, which calls to SchemaParser for some
metadata (the positions of the trees in "data" file). After that it goes
through the tree and read up the rows using HsqlRowInputStream.

Finally, it uses sdbc's XPreparedStatement to insert the rows to the
actual database.

Change-Id: If4b17572e5989c218d45880bc3fd5a8820bb4101
Reviewed-on: https://gerrit.libreoffice.org/50536
Reviewed-by: Tamás Bunth 
Tested-by: Tamás Bunth 

commit 95bece38ac5c943657ad959cad148c84a91d45a4
Author: Tamas Bunth 
Date:   Mon Jan 8 15:57:39 2018 +0100

Add HSQLDB schema import

It can be enabled by initializing the DBACCESS_HSQL_MIGRATION variable.

Create new library "dbahsql" which is responsible for migrating the
embedded hsql database to any database covered by sdbc.

The hsqldb schema is stored in a file named "script" in form of SQL
statements. The SQL statements used by DBMS's differ mostly by the
defined types. Because of that, only the create statements need to be
parsed, alter statements will work (with a little luck) without actually
modifying it.

User / security settings which can occur in the script file (e.g. GRANT
statements) are dropped. Statements starting with SET are also dropped
(they are hsql specific stuff)

Change-Id: I6a22942e8a9a76765f80e50f0ad68f4d72e1ff9d
Reviewed-on: https://gerrit.libreoffice.org/48260
Tested-by: Jenkins 
Reviewed-by: Tamás Bunth 

Yup.

>From the name I'd put it into -sdbc-hsqldb but that is too opaque and more
hidden and  subject to go away anyway when hsqldb finally was removed, which I 
can't wait for :))

We already put libdbalo.so into a -base-core. That would mean a simple 
(untested as of yet)

diff --git a/control.in b/control.in
index d747781b..0997189d 100644
--- a/control.in
+++ b/control.in
@@ -330,15 +330,17 @@ Depends: libreoffice-core (= ${binary:Version}),
  ${misc:Depends},
  ${shlibs:Depends}
 Suggests: libreoffice-base
+Replaces: libreoffice-base-drivers (<< 1:6.1.1~rc1-2)
 Description: office productivity suite -- shared library
  LibreOffice is a full-featured office productivity suite that provides
  a near drop-in replacement for Microsoft(R) Office.
  .
- This package contains libdba, a common library of the LibreOffice
- suite used by Base, Writer and Calc.
+ This package contains common libraries of LibreOffice Base used by
+ Base, Writer and Calc.
  .
  If you need full Base functionality (or actual database drivers), please
- install libreoffice-base.
+ install libreoffice-base (and/or libreoffice-base-drivers and/o
+ libreoffice-sdbc-*).
 
 Package: libreoffice-base
 Architecture: %OOO_BASE_ARCHS%
diff --git a/rules b/rules
index 0db588ea..4a8fa393 100755
--- a/rules
+++ b/rules
@@ -2756,6 +2756,8 @@ ifeq "$(PACKAGE_BASE)" "y"
mkdir -p $(PKGDIR)-base-core/$(OODIR)/program
mv $(PKGDIR)-base/$(OODIR)/program/libdbalo.so \
$(PKGDIR)-base-core/$(OODIR)/program
+   mv $(PKGDIR)-base/$(OODIR)/program/libdbahsqllo.so \
+   $(PKGDIR)-base-core/$(OODIR)/program
 endif
 
 ifeq "$(ENABLE_JAVA)" "y"

(+ regen of control)

should do it?

Regards,

Rene

Bug#907397: libreoffice: writer crashes when trying to insert more fields

[Rene Engelhard]

retitle 907397 libreoffice: writer crashes when trying to insert more fields 
without libreoffice-base-drivers
thanks

Hi,

On Mon, Aug 27, 2018 at 07:06:04PM +0200, Rene Engelhard wrote:
> We already put libdbalo.so into a -base-core. That would mean a simple 
> (untested as of yet)
> 
> diff --git a/control.in b/control.in
> index d747781b..0997189d 100644
> --- a/control.in
> +++ b/control.in
> @@ -330,15 +330,17 @@ Depends: libreoffice-core (= ${binary:Version}),
>   ${misc:Depends},
>   ${shlibs:Depends}
>  Suggests: libreoffice-base
> +Replaces: libreoffice-base-drivers (<< 1:6.1.1~rc1-2)
>  Description: office productivity suite -- shared library
>   LibreOffice is a full-featured office productivity suite that provides
>   a near drop-in replacement for Microsoft(R) Office.
>   .
> - This package contains libdba, a common library of the LibreOffice
> - suite used by Base, Writer and Calc.
> + This package contains common libraries of LibreOffice Base used by
> + Base, Writer and Calc.
>   .
>   If you need full Base functionality (or actual database drivers), please
> - install libreoffice-base.
> + install libreoffice-base (and/or libreoffice-base-drivers and/o
> + libreoffice-sdbc-*).
>  
>  Package: libreoffice-base
>  Architecture: %OOO_BASE_ARCHS%
> diff --git a/rules b/rules
> index 0db588ea..4a8fa393 100755
> --- a/rules
> +++ b/rules
> @@ -2756,6 +2756,8 @@ ifeq "$(PACKAGE_BASE)" "y"
> mkdir -p $(PKGDIR)-base-core/$(OODIR)/program
> mv $(PKGDIR)-base/$(OODIR)/program/libdbalo.so \
> $(PKGDIR)-base-core/$(OODIR)/program
> +   mv $(PKGDIR)-base/$(OODIR)/program/libdbahsqllo.so \
> +   $(PKGDIR)-base-core/$(OODIR)/program
>  endif
>  
>  ifeq "$(ENABLE_JAVA)" "y"
> 
> (+ regen of control)
> 
> should do it?

Committed the above.

Regards,

Rene

Bug#906745: libreoffice-calc: LibreOffice-Calc takes all available memory and freezes system when open a file

[Rene Engelhard]

[ please keep bugs in Cc to discussions are recorded. ]

Hi,

On Tue, Aug 21, 2018 at 10:25:36AM +0800, Jun Jiang wrote:
>I've fixed it and now all dependencies are marked "ii" and both
>libreoffice and libreoffice-core are shown as "APT-Manual-Installed: yes"
>in the ouput of apt show. I'll examine whether libreoffice behaves at
>current status and will report if the problem persists.

Ping? :) And? :)

Regards,

Rene

Bug#906987: libreoffice-kde5: lo_kde5filepicker has 100% CPU utilization

[Rene Engelhard]

tag 906987 + moreinfo
thanks

Hi,

On Wed, Aug 22, 2018 at 10:53:41PM +0200, Rainer Dorsch wrote:
> I do not know what these instances are doing or who started them, since 
> libreoffice itself is not even running

You yourself once? lo_kde5filepicker is the current workaround for
getting a KDE5 native filepicker in LO. It does interprorcess
communication..

> rd@b370:~$ ps uaxwww|grep libreoffice
> rd1793 92.3  0.5 676972 83884 ?Rl   18:46 226:30 
> /usr/lib/libreoffice/program/lo_kde5filepicker -session 
> 10623337315338463690015520089_1534956113_564848
> rd1834 92.3  0.5 676944 84012 ?Rl   18:46 226:30 
> /usr/lib/libreoffice/program/lo_kde5filepicker -session 
> 10623337315338464080015520090_1534956113_565286
> rd   14964  0.0  0.0   2368   808 pts/2S+   22:48   0:00 sh -c 
> /usr/bin/sensible-editor  
> '/tmp/reportbug-libreoffice-kde5-20180822-14898-bpdkewiq'
> rd   14965  0.0  0.0   2368   808 pts/2S+   22:48   0:00 /bin/sh 
> /usr/bin/sensible-editor 
> /tmp/reportbug-libreoffice-kde5-20180822-14898-bpdkewiq
> rd   14974  0.0  0.0  10416  6360 pts/2S+   22:48   0:00 nano 
> /tmp/reportbug-libreoffice-kde5-20180822-14898-bpdkewiq
> rd   15048  0.0  0.0   5084   936 pts/3S+   22:51   0:00 grep 
> libreoffice
> rd@b370:~$ 

.. so if there is no LO anymore it probably tries to communicate with a
LO which isn't there anymore?

But it was once and you opened/saved files?

> I saw a similar report for gentoo:
> 
> https://forums.gentoo.org/viewtopic-t-1083586.html?sid=76f37e6cfa80566337f52334669e0d04

Which doesn't say anything.

> As a workaround I try to deinstall libreoffice-kde5 again :-/

Or just kill those processes if no LO is running? (btw, looking for LO
is better done with soffice.bin, not libreoffice)

Regards,

Rene

Bug#906745: libreoffice-calc: LibreOffice-Calc takes all available memory and freezes system when open a file

[Rene Engelhard]

tag 906745 + moreinfo
thanks

Hi,

On Mon, Aug 20, 2018 at 09:52:11PM +0800, Jiang Jun wrote:
> LibreOffice-Calc just became extremely unstable lately.
> When I opened a regular csv file with about 200~300 rows x 5~10 columns, the
> dialogue popped out
> to let me choose the proper separator, which in my case was comma. Right after
> I clicked OK to open
> the file, LibreOffice-Calc took all available memory and soon froze the whole
> system. The whole process
> happened really fast, typically in less than 10 sec I think. When desktop was
> forzen, keyboard and touchpad
> failed to work anymore or worked with a really long lag(more than 20 sec
> maybe). Ctrl + Alt + F2 to switch
> to tty would hang on a black screen and tty login prompt never showed up. Only
> thing I could do was to
> long press power button to restart, or SysRq method worked last time I tried.


Not that it is related (or at least might now) but...

> pn  libhyphen0
[...]
> pn  librevenge-0.0-0   

But how did you get here? This is a dependency. Of libreoffice-core.
Since aages.

TTBOMK librevenge is base of various filter and those are part of the
type detetction...

So how did you install LO Calc without it?

Can you fix your system, get a clean state of the packages, before
trying anything?

(Yes, I read your purged everything and reinstalled - but still
libreoffice-core Depends: on the above)

Regards,

Rene

Bug#906726: libreoffice printing bug

[Rene Engelhard]

severity 906726 important
tag 906726 + moreinfo
found 906726 1:6.1.0-1
forwarded 906726 https://bugs.documentfoundation.org/show_bug.cgi?id=119357
thanks

On Mon, Aug 20, 2018 at 09:47:04AM +0100, Mark van Rossum wrote:
> Version: 6.1.0
> Severity: medium

Neither of this are valid entries. This it automatically parsed, so you 
shiould add proper values. (And version here is the Debian package
version.)

Your report ended up as "normal" and affecting anything in history back
to "openoffice", which is definitely not true, as you say yourself
below.

> I wanted to make you aware that, the  libreoffice 6.1 update lead to a
> printing bug where no postscript text output is produced.
> By reverting back to version 6.0.6 is was resolved.

And what about printing as PDF? See bugs.debian.org/95431

Regards,

Rene

Bug#905196: nmu: pike8.0_8.0.610-1

[Rene Engelhard]

Hi,

On Sat, Aug 11, 2018 at 11:43:25PM +0300, Adrian Bunk wrote:
> On Wed, Aug 01, 2018 at 08:20:41PM +0800, Boyuan Yang wrote:
> >...
> > Please consider making another upload to make sure that pike8.0 is
> > built against new libsass / libsass1 library. BinNMU might be
> > applicable but considering that the Testing migration is already
> > blocked by some other problems [2], it might be better to fix the
> > problem together with another upload.
> 
> The other problem is only related to cruft, so a binNMU is sufficient:
> 
> nmu pike8.0_8.0.610-1 . amd64 arm64 armhf i386 mips mipsel ppc64el s390x . 
> unstable . -m "Rebuild with libsass1"

Which now picked up a dependency on libsane1 (see then
uncoordinated/-wanted yet libsane transition and #905913)

Regards,

Rene

Bug#905874: libreoffice: No input of accented characters through dead-key composition

[Rene Engelhard]

On Sat, Aug 11, 2018 at 05:20:54PM -0400, Mario L. Epp K. wrote:
> On 08/11/2018 09:58 AM, Rene Engelhard wrote:
> > retitle 905874: libreoffice: No input of accented characters through 
> > dead-key composition in gen and kde4 plugins
> > thanks
> > 
> > On Sat, Aug 11, 2018 at 01:22:51PM +0200, Rene Engelhard wrote:
> > > On Fri, Aug 10, 2018 at 10:18:30PM -0400, Mario L. Epp wrote:
> > > > On researching the issue prior to making this report, I found this issue
> > > > reported on the DocumentFoundation Bugzilla as "Bug 112770" at
> > > > <https://bugs.documentfoundation.org/show_bug.cgi?id=112770>. But I am 
> > > > not
> > > > shure how to implement the solution from 6.0.0 to 5.2.7.2 for KDE5 on 
> > > > Debian 9.
> > > 
> > > Maybe install the 6.1.0 backport from stretch-backports? That one also
> > > has a KDE5 integration other than that KDE4 thingy "working" with KDE5.
> > > 
> > > This will never be fixed in stable properly (until buster releases of
> > > course with above new KDE5 integration)
> 
> I uninstalled the "stable" LibreOffice before installing the "backported"
> LibreOffice with the Metapackage. After the instalation I rebooted the
> computer.

The metapackage doesn't install the KDE integration.

> But the same bug appears also in LibreOffice 6.1.0.2 (Build ID:
> 1:6.1.0~rc2-3~bpo9+1), Linux 4.9; UI render: defualt; VCL: x11.

And with the KDE integration actually installed? That would just leave
the non-integrated LO affected only.

Regards,

Rene

Bug#905874: libreoffice: No input of accented characters through dead-key composition

[Rene Engelhard]

retitle 905874: libreoffice: No input of accented characters through dead-key 
composition in gen and kde4 plugins
thanks

On Sat, Aug 11, 2018 at 01:22:51PM +0200, Rene Engelhard wrote:
> On Fri, Aug 10, 2018 at 10:18:30PM -0400, Mario L. Epp wrote:
> > On researching the issue prior to making this report, I found this issue
> > reported on the DocumentFoundation Bugzilla as "Bug 112770" at
> > <https://bugs.documentfoundation.org/show_bug.cgi?id=112770>. But I am not
> > shure how to implement the solution from 6.0.0 to 5.2.7.2 for KDE5 on 
> > Debian 9.
> 
> Maybe install the 6.1.0 backport from stretch-backports? That one also
> has a KDE5 integration other than that KDE4 thingy "working" with KDE5.
> 
> This will never be fixed in stable properly (until buster releases of
> course with above new KDE5 integration)

I missed to mention that I repeatedly asked whether there were any
important fixes for KDE4 which should be backported to 5.2.7 as for
stretch; no reply, and at some point in time it was too late.

OK, this time according  to the upstream bug this also affects "gen",
but most people will use gtk3/gtk2 or kde(4)...

Regards,
 
Rene

Bug#905819: libreoffice-writer: forms check box controls lost

[Rene Engelhard]

Source: libreoffice
Version: 1:6.1.0~rc2-3
Severity: importtant

Hi,

On Thu, Aug 09, 2018 at 09:44:48PM +0200, Albrecht Dreß wrote:
> in the LibreOffice package as specified above (stretch-backports), adding a 
> check box form control in Writer (and other components like base as well) 
> produces an item without the actual check box control.
> 
> To reproduce:
> - Either create a new document, add a check box form: the item is created 
> with the default title, but without the check box control
> - or open a document created by an older LibreOffice version: e.g. a Base 
> form containing check boxes.  In this LO version, the titles are still there, 
> but the controls are gone.
> 
> Example screenshot (Base, using German locale): 
> 
> See also the thread 
> .

http://bugs.debian.org/904598
http://bugs.debian.org/905408

Also see my post to the libreoffice development list. (Can't yut'n'paste
this here...)

So it also happens for inserted controls? sigh. (and that this time also
in gtk, probably because those controls are rendered by LO...)

> The "official" package from de.libreoffice.org 
> (LibreOffice_6.1.0_Linux_x86-64_deb.tar.gz, SHA1 = 
> a48fceeed811a19271fd5d858c7368f981aa2e89) does *not* have this bug, i.e. 
> adding check box form controls works as expected.

Sigh. Feared that given the replies on libreoff...@lists.freedesktop.org

egards,

Rene

P.S.:
> Note that I classified this bug as important as the check boxes disappear 
> from existing documents, making them unusable (a database frontend in my 
> case).

Not that this bug report didn't end up as a "real" filed bug report at all 
since you
reported it against a backport bversipon and thus it immediately gets
redirected to "just" a mail to debian-backports ;) (and if, the BTS
iwould not know the bpo version anyway.)

Will make one out of it and set you as submitter.

Bug#905442: AppArmor: cannot save files in enforced mode

[Rene Engelhard]

tag 905442 - moreinfo
thanks

Hi,

On Tue, Aug 07, 2018 at 02:14:09PM +0300, Vincas Dargis wrote:
> n 8/7/18 1:55 PM, Rene Engelhard wrote:
> > Sorry, apparently didn't read fully the first time I read this mail.
> > 
> > Really $HOME? I would be surprised.
> > 
> > I know there's lu??.tmps in /tmp (or $TMPDIR) but $HOME?
> > Did you set TMPDIR=$HOME?
> 
> No, TMPDIR is not set. LO additionally tries to save .tmp file in the same
> directory where .odt is being saved:

Hrm, ok.

Regards,

Rene

Bug#905442: AppArmor: cannot save files in enforced mode

[Rene Engelhard]

tag 905442 + moreinfo
thanks

Hi,

On Sat, Aug 04, 2018 at 06:45:07PM +0300, Vincas Dargis wrote:
> I cannot save files when AppArmor profile is in enforce mode:
> 
> ```
> type=AVC msg=audit(1533396515.983:974): apparmor="DENIED"
> operation="mknod" profile="libreoffice-soffice"
> name="/home/vincas/lu27901fkol0k.tmp" pid=27901 comm="soffice.bin"


Sorry, apparently didn't read fully the first time I read this mail.

Really $HOME? I would be surprised.

I know there's lu??.tmps in /tmp (or $TMPDIR) but $HOME?
Did you set TMPDIR=$HOME?

That would make this invalid here. Stuff like this needs changing on various
places then (e.g. for my print server and the cups profile I needed to
allow the stuff out of /data/var instead of/additionally to /var - which is 
where
/var is moved out from the microSD card of this rpi3 ;-))

Regards,

Rene

Bug#887593: More apparmor="ALLOWED" messages in syslog.

[Rene Engelhard]

Hi,

On Sat, Aug 04, 2018 at 05:50:35PM +0300, Vincas Dargis wrote:
> intrigeri, could we get opencl abstractions in 2.13, or we are expecting to 
> get AppArmor 3 in Buster?
> 
> BTW I have proposed update to use `dri-enumerate` abstraction and remove 
> backported rule:
> https://gerrit.libreoffice.org/#/c/58589/

As I said upstream I am not sure about this upstream.

But for Debian we could (we know the AA version) do that, sure.

https://salsa.debian.org/libreoffice-team/libreoffice/libreoffice/commit/5e887f9e973f448672befe428d81b0379a00a43c

Regards,

Rene
> 

Bug#905408: libreoffice-writer: Confirming missing radio buttons and checkbox

[Rene Engelhard]

On Mon, Aug 06, 2018 at 08:47:27AM +0100, Henry Bremridge wrote:
[ missing text ... yes, I knw ot's in the subject but ...]
> As an example: format | paragraph | Alignment
> 
> There are no check boxes to select left justify right etc

And https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=904598

> This is common.

I know, see above..

Let's see what upstream replies to my mail to the upstream mailing list.

Regards,

Rene

Bug#905431: libreoffice-common: LibreOffice fails to print text unless "PDF as standard print job format" is chosen

[Rene Engelhard]

tag 905431 + moreinfo
tag 905431 + unreproducible
thanks

Hi,

On Sat, Aug 04, 2018 at 02:41:27PM +0100, Andrew Rule wrote:
> Upon further investigation, I found that enabling the option "PDF as standard
> print job format" allows the application to print as normal.
> 
> I did test this on two printers, so I am sure it is not a problem with a
> specific printer.  Furthermore, both Okular and MuseScore packages print with
> no special settings on the computer.
> 
> As I presume the attached information tells you, I print using CUPS, which is
> currently 2.2.8-5

Can't reproduce this. LO on buster with CUPS from buster (so same
versions as in sid. print server also is buster). No special settings
ttbomk and it just prints a test document just saying "Test" just fine.

Regards,

Rene

Bug#905442: AppArmor: cannot save files in enforced mode

[Rene Engelhard]

Hi,

On Sat, Aug 04, 2018 at 06:45:07PM +0300, Vincas Dargis wrote:
> I cannot save files when AppArmor profile is in enforce mode:

Ugh.

> So `...something.../lu???.tmp rw` rule would fix that (eleven
> changing possitions)
> 
> I'll try to propose fix in upstream gerrit.

Thanks.

Regards,

Rene

Bug#905408: libreoffice: missed radiobuttons and checkbox in forms

[Rene Engelhard]

found 905408 1:6.1.0~rc2-3
retitle 905408 libreoffice: missed radiobuttons and checkbox in forms
with gen VCLplug
thanks

On Sat, Aug 04, 2018 at 08:46:12AM +0200, Kamil Jonca wrote:
> Source: libreoffice
> Version: 3a6.1.0~rc2-3

Please a bit more care, this isn't a valid version.

> I found that in my database forms, at version 6.1 libreoffice, all checkboxes 
> and radiobuttons are missing. 
> Only their labels exist, but no field to enter/check value. 
> Simplest way to observe it is to run: 
> soffice -base
> and try to choose 'open existing database file'

Confirmed. :-(

Only happens on "gen" VCLplug.. - aka without any gtk(2/3) or kde
integration.

Regards,

Rene

Bug#904598: libreoffice: Find/Replace dialogs' options are broken

[Rene Engelhard]

On Thu, Jul 26, 2018 at 09:00:20AM +0200, Rene Engelhard wrote:
> On Wed, Jul 25, 2018 at 10:19:15AM -0400, Michael Welsh Duggan wrote:
> > Package: libreoffice
> > Version: 1:6.1.0~rc2-3
> > Severity: important
> > 
> > Dear Maintainer,
> > 
> > Libreoffice's find/replace dialogs' options have become partially hidden
> > and unusable.  Seen in writer and impress.  I've included a picture of
> > the dialog from writer.
> 
> I can confirm this - but also with export SAL_USE_VCLPLUGIN="gen" aka
   
   only

Regards,

Rene
> 

Bug#904598: libreoffice: Find/Replace dialogs' options are broken

[Rene Engelhard]

retitle 904598 libreoffice: Find/Replace dialogs' options are broken in gen 
vclplug
tag 904598 + confirmed
thanks

Hi,

On Wed, Jul 25, 2018 at 10:19:15AM -0400, Michael Welsh Duggan wrote:
> Package: libreoffice
> Version: 1:6.1.0~rc2-3
> Severity: important
> 
> Dear Maintainer,
> 
> Libreoffice's find/replace dialogs' options have become partially hidden
> and unusable.  Seen in writer and impress.  I've included a picture of
> the dialog from writer.

I can confirm this - but also with export SAL_USE_VCLPLUGIN="gen" aka
"generic pligin". It doesn't happen in e.g -gtk3 (only thing I quickly
tested this morning on a uptodate buster)

Regards,

Rene

Bug#904457: tasksel: please (re)add libreoffice-kde5 to task-kde-desktop

[Rene Engelhard]

Package: tasksel
Version: 3.44
Severity: wishlist
Tags: patch

Hi,

libreoffice-kde got removed from the kde-desktop task once because it
was not built anymore because it was for Qt4/KDE4.

Now with LibreOffice 6.1 it's available again (as libreoffice-kde5, -kde
was readded as a transitional package). So please (re)add
libreoffice-kde5 to the task.

In alioth I had commit rights but in salsa I don't have (yet) so this
bug and:

Patch/MR at http://salsa.debian.org/installer-team/tasksel/merge_requests/2

Regards,

Rene

Bug#894153: the bugs seems to be fixed now

[Rene Engelhard]

On Fri, Jul 20, 2018 at 11:07:40AM +0200, Rene Engelhard wrote:
> close 89153 1:6.0.6~rc1-1
> thanks
[...]
> What about the 6.1.0 rc1 in experimental? Is it fixed there, too?
> (or only in rc2 - which isn't officially released yet). Since
[...]
> (I plan to upload said 6.1.0 rc2 to unstable soonish after it "survived"
> a test build in experimenal when it's there and uploaded.)

Ping? :)

That now happened.

Would try myself, but apparently I am not skkilled anpough to actually
make Ctrl-U 61 print anything else than a "61". How are you supposed to
do that?

Regards,
 
Rene
> > 
> 

Bug#904312: libreoffice-help-en-us: dependency on firefox-esr

[Rene Engelhard]

severity 904312 minor
thanks

Hi,

On Mon, Jul 23, 2018 at 10:05:15AM +0200, Jörg-Volker Peetz wrote:
> the dependency on concrete web browser packages is missing firefox. Why

Intentional. firefox is not in testing or stable. We package software
for stable in the end, so I left it out...

> not just depend on www-browser?

Because it needs Javascript and the text bvrowsers don't provide it?

Besides that, see #904022.

Regards,

Rene

Bug#894153: the bugs seems to be fixed now

[Rene Engelhard]

close 89153 1:6.0.6~rc1-1
thanks

Hi,

On Fri, Jul 20, 2018 at 10:17:51AM +0200, Luc Maisonobe wrote:
> I don't know when or why it happened, but as of 2018-07-20
> and version 1:6.0.6~rc1-1, the bug doesn't happen anymore.
> 
> I now can use Ctrl-U prefix in libreoffice just like I use
> it in other desktop applications to input any unicode character.

MMh, ok. Marking as such.

What about the 6.1.0 rc1 in experimental? Is it fixed there, too?
(or only in rc2 - which isn't officially released yet). Since
6.0 and 6.1 are different "branches" for the BTS' version-tracking we
need to explicitely set the 6.1 version, too...

(I plan to upload said 6.1.0 rc2 to unstable soonish after it "survived"
a test build in experimenal when it's there and uploaded.)

Regards,

Rene
> 

Bug#904022: libreoffice-help-common: depends on odd virtual package x-www-browser

[Rene Engelhard]

On Wed, Jul 18, 2018 at 11:56:27AM +0200, Jonas Smedegaard wrote:
> libreoffice-help-common and a range of libreoffice-help-* packages in
> experimental depends on virtual package x-www-browser.
> 
> That virtual package seems fishy: It is provided only by qutebrowser.

Interesting. I didn't recheck the providers of it when I added it.

> Dependencies should be deterministic, which implies that virtual
> packages should generally be declared only as a fallback - the exception
> being virtual packages known to only ever be provided by a single real
> package.
> 
> If intent was to depend on any X11-based web browser, then I believe the
> correct (although imperfect) approach currently is this:
> 
>   Depends: firefox-esr | gnome-www-browser

The intent is to depend on any JavaScript capable (and I assume all
X11-based web browser is) web browser.

> That can later be improved by a) convincing more browser packages to
> provide virtual package x-www-browser (including non-GNOME ones), and

I could have sworn many did once.

*sigh*, ok, let's do firefox-esr | gnome-www-browser | konqueror. That
should match most of the sensible ones.

Regards,

Rene

Bug#904022: libreoffice-help-common: depends on odd virtual package x-www-browser

[Rene Engelhard]

Hi,

On Wed, Jul 18, 2018 at 02:29:55PM +0200, Rene Engelhard wrote:
> On Wed, Jul 18, 2018 at 11:56:27AM +0200, Jonas Smedegaard wrote:
> > libreoffice-help-common and a range of libreoffice-help-* packages in
> > experimental depends on virtual package x-www-browser.
> > 
> > That virtual package seems fishy: It is provided only by qutebrowser.
> 
> Interesting. I didn't recheck the providers of it when I added it.
[...]
> I could have sworn many did once.

Ah, I see. I assumed packages providing the x-www-browser alternative
also provide the x-www-browser virtual package. Which obviously is not
the case...

Regards,
 
Rene

Bug#903900: libreoffice-common: missing AppArmor entries

[Rene Engelhard]

On Tue, Jul 17, 2018 at 07:34:19AM +0200, Rene Engelhard wrote:
> I've not added any specific driver allowance, and if this is for the 
> proprietary
> nvidia driver I am not going to do so.
> 
> If so, that basically leaves /etc/java-?-openjdk/security/java.security r,
> - which again proves that you shouldn't mix various things in one report

Nevermind, early mail which (apparently) didn't get out this morning but got
out now  that I woke up the laptop.

As said, java.security will be fixed in the next upload.

Regards,
 
Rene

Bug#903900: libreoffice-common: missing AppArmor entries

[Rene Engelhard]

severity 903900 wishlist
tag 903900 + moreinfo
thanks

Hi,

On Mon, Jul 16, 2018 at 12:42:30PM +0100, Nuno Oliveira wrote:
> Package: libreoffice-common
> Version: 1:6.0.6~rc1-1
> Severity: normal
> 
> The following seem to be required, to avoid AppArmor from complaining from 
> file
> acess:
> 
> ### Extra:
> /dev/nvidia0 rw,
> /dev/nvidiactl rw,
> /dev/nvidia-modeset rw,

For what is this? Nvidias driver? nouveau?

> /etc/java-8-openjdk/security/java.security r,

Uuhm, use default-jdk (10).
But yeah, we probably should allow it

> owner /tmp/.gl* rwm,
> /proc/driver/nvidia/params r,

Again, nvidia.

> /proc/modules r,
> /sys/devices/system/memory/block_size_bytes r,

What for? Also for nvidia?

> /usr/share/nvidia/nvidia-application-profiles-* r,

Nvdia.

I've not added any specific driver allowance, and if this is for the proprietary
nvidia driver I am not going to do so.

If so, that basically leaves /etc/java-?-openjdk/security/java.security r,
- which again proves that you shouldn't mix various things in one report

Regards,

Rene

Bug#903900: libreoffice-common: missing AppArmor entries

[Rene Engelhard]

retitle 903900 libreoffice-common: apparmor denies java.security access
severity 903900 - moreinfo
tag 903900 normal
thanks

Hi,

On Tue, Jul 17, 2018 at 09:21:42AM +0200, Rene Engelhard wrote:
> > /etc/java-8-openjdk/security/java.security r,
> ^
> (Almost) valid. Though I wonder why LO wants this.
> But I think you should use the default JRE (10)...

Using doPrivileged in LOs Java code needs it.

/usr/lib/jvm/** r is allowed, though, but this
(/conf/security/java.security) is a symlink and so (ttbomk)
apparmor still denies it... ;-(

I'll stick a allowance of /etc/java-??-openjdk/security/java.security r in
as a Debian-specific patch...

> So part os it shouldn't be fixed here, and this is a good example
> why mixing two different stuff (here: nvidia and java.security) in
> one report is bad.

Let's use this report only for java.security.

Regards,
 
Rene
> 

Bug#903900: libreoffice-common: missing AppArmor entries

[Rene Engelhard]

severity 903900 minor
tag 903900 + moreinfo
thanks

On Mon, Jul 16, 2018 at 12:42:30PM +0100, Nuno Oliveira wrote:
> ### Extra:
> /dev/nvidia0 rw,
> /dev/nvidiactl rw,
> /dev/nvidia-modeset rw,

Nvidia. And looks like the proprietary driver.
(I don't use nvidia cards myself, a IRC query makes people
tell me this looks like the proprietary nvidia driver.)

> /etc/java-8-openjdk/security/java.security r,
^
(Almost) valid. Though I wonder why LO wants this.
But I think you should use the default JRE (10)...

> owner /tmp/.gl* rwm,
> /proc/driver/nvidia/params r,
> /proc/modules r,
> /usr/share/nvidia/nvidia-application-profiles-* r,

Again Nvidia and the properietary driver.

> /sys/devices/system/memory/block_size_bytes r,

No idea what this does, though. Maybe something done by
the nvidia driver, too?

Even if it was a driver which one is supposed to care about
LO is not using those devices/files directly but going over
libGL, so *that* one has to ship profiles allowing it's use.
(or it being put into some standard abstraction.

So part os it shouldn't be fixed here, and this is a good example
why mixing two different stuff (here: nvidia and java.security) in
one report is bad.

Regards,

Rene

Bug#901220: libreoffice-dictionaries: FTBFS: can't cd to /<>/debian/hunspell-es/usr/share/hunspell

[Rene Engelhard]

Hi,

On Sun, Jun 10, 2018 at 10:56:31AM +0200, Andreas Beckmann wrote:
> libreoffice-dictionaries/experimental FTBFS:
> 
> https://buildd.debian.org/status/fetch.php?pkg=libreoffice-dictionaries=all=1%3A6.1.0%7Ebeta1-1=1527247064=0

Yes, I have seen this. I *do* look at buildlogs after uploads.

This is experimental and this is a pure data
package with contents which ideally shouldn't be there at all but built
from wherever they come from, so I didn't immediately fix it.

Will be fixed with a subsequent upload, whenever this will happen.
Probably with beta2.

Regards,

Rene

Bug#899380: libreoffice-common: AppArmor profile prohibits encrypting documents with GPG

[Rene Engelhard]

On Wed, May 23, 2018 at 10:22:24AM -0400, John Scott wrote:
> With Java 10 installed, I also get this:
> 
> apparmor="ALLOWED" operation="exec" profile="libreoffice-soffice" 
> name="/usr/lib/jvm/java-10-openjdk-amd64/bin/java" pid=2320 
> comm="osl_executeProc" requested_mask="x" denied_mask="x" fsuid=1000 ouid=0 
> target="libreoffice-soffice//null-/usr/lib/jvm/java-10-openjdk-amd64/bin/java"
> 
> I don't know much about AppArmor, but I noticed the
> profile has this line in it:
> 
> /usr/lib{,32,64}/jvm/**/jre/bin/java  mix,
> 
> which only differs from the path LibreOffice was
> accessing by there being no jre/ in the latter, if
> that could explain the cause.

Looks like Java 8 has jre/java and 9 and 10 only bin/java, so I did

$ git diff HEAD^^ HEAD sysui/desktop/apparmor/program.soffice.bin
diff --git a/sysui/desktop/apparmor/program.soffice.bin 
b/sysui/desktop/apparmor/program.soffice.bin
index 8ce7cbc171c1..2fc7fd6b5735 100644
--- a/sysui/desktop/apparmor/program.soffice.bin
+++ b/sysui/desktop/apparmor/program.soffice.bin
@@ -143,6 +143,7 @@ profile libreoffice-soffice INSTDIR-program/soffice.bin {
   /usr/lib{,32,64}/jvm/ r,
   /usr/lib{,32,64}/jvm/**   r,
   /usr/lib{,32,64}/jvm/**/jre/bin/java  mix,
+  /usr/lib{,32,64}/jvm/**/bin/java  mix,
   INSTDIR-**rw,
   INSTDIR-**.so m,
   INSTDIR-program/soffice.bin   mix,

upstream. Thanks for the pointer.

Regards,

Rene

Bug#899380: libreoffice-common: AppArmor profile prohibits encrypting documents with GPG

[Rene Engelhard]

On Wed, May 23, 2018 at 01:50:08PM -0400, John Scott wrote:
> That happened to me too because I didn't use a trusted
> key the first time. When I encrypted to my own public
> key, then it froze.

Confirmed (Took the wrong key in LOs list, the list is not intuitive
enough.)

It looks like this is about .gnupg/random_seed. While it hangs it
constantly complains about this in kern.log:

May 23 21:04:07 frodo kernel: [277802.848361] audit: type=1400
audit(1527102247.170:1551): apparmor="DENIED" operation="file_lock"
profile="libreoffice-soffice//gpg" name="/home/rene/.gnupg/random_seed"
pid=20251 comm="gpg" requested_mask="k" denied_mask="k" fsuid=1000
ouid=1000

- as you pasted already. So it tries to get the lock and doesn't get it,
tries again, fails, waits, tries again, fails, ...

When I allow k ("locking") for random_seed with

owner @{HOME}/.gnupg/random_seed rk,

it doesn't hang anymore.

Regards,

Rene

Bug#899380: libreoffice-common: AppArmor profile prohibits encrypting documents with GPG

[Rene Engelhard]

tag 899380 - moreinfo
tag 899380 - unreproducible
thanks

Hi,

On Wed, May 23, 2018 at 01:03:32PM -0400, John Scott wrote:
> I'm afraid there's a misunderstanding. I wasn't referring
> to signing: I had been checking the "Encrypt with GPG key"
> in the Save As dialog. Encrypting it to my own public key
> causes it to freeze. Signing works fine, though.

Ah, right, bad reading from my side, sorry.

I don't get a freeze but a

"OpenPGP key not trusted, damaged, or encryption failure. Please try
again."

but that incidentially also with the profile aa-complain'ed
(Then again my key is on a smartcard.)

Regards,

Rene

Bug#899380: libreoffice-common: AppArmor profile prohibits encrypting documents with GPG

[Rene Engelhard]

tag 899380 + moreinfo
tag 899380 + unreproducible
thanks

Hi,

On Wed, May 23, 2018 at 10:22:24AM -0400, John Scott wrote:
> apparmor="DENIED" operation="open" profile="libreoffice-soffice//gpg" 
> name="/home/john/.gnupg/trustdb.gpg" pid=2308 comm="gpg" requested_mask="w" 
> denied_mask="w" fsuid=1000 ouid=1000
> apparmor="DENIED" operation="file_lock" profile="libreoffice-soffice//gpg" 
> name="/home/john/.gnupg/random_seed" pid=2804 comm="gpg" requested_mask="k" 
> denied_mask="k" fsuid=1000 ouid=1000

Did it really fail to sign?

I tried that once when this was new Worked for me (the gpg stuff there
is actually from me.).

Let's try now, though, current buster.

root@frodo:/home/rene# aa-status
apparmor module is loaded.
33 profiles are loaded.
31 profiles are in enforce mode.
[...]
   libreoffice-soffice//gpg
[...]
2 profiles are in complain mode.
   libreoffice-oopslash
   libreoffice-soffice
[...]
root@frodo:/home/rene# aa-enforce 
/etc/apparmor.d/usr.lib.libreoffice.program.soffice.bin 
Setting /etc/apparmor.d/usr.lib.libreoffice.program.soffice.bin to enforce mode.
root@frodo:/home/rene# aa-status
apparmor module is loaded.
33 profiles are loaded.
32 profiles are in enforce mode.
[...]
   libreoffice-soffice
   libreoffice-soffice//gpg
[...]
root@frodo:/home/rene#
root@frodo:/home/rene# /etc/init.d/apparmor reload
[ ok ] Reloading apparmor configuration (via systemctl): apparmor.service.

Can sign just fine.

(but yes, I get the DENIED, too)

> I'd hate to cram two unrelated bugs in one report, but
> since the fixes will be in the AppArmor profiles anyway,
> I hope you don't mind.

Actually I do :-)

Regards,

Rene

Bug#899129: error: 'char16_t' does not name a type; did you mean 'wchar_t'? (Was: Bug#899129: prime-phylo: FTBFS: cd obj-x86_64-linux-gnu && make -j8 -Oline returned exit code 2)

[Rene Engelhard]

On Sun, May 20, 2018 at 12:20:05PM +0500, Andrey Rahmatullin wrote:
> On Sun, May 20, 2018 at 09:05:48AM +0200, Andreas Tille wrote:
> > cd /build/prime-phylo-1.0.11/obj-x86_64-linux-gnu/src/cxx/libraries/prime 
> > && /usr/bin/c++  -DONLY_ONE_TIMESAMPLE -DPERTURBED_NODE 
> > -Dprime_phylo_EXPORTS 
> > -I/build/prime-phylo-1.0.11/obj-x86_64-linux-gnu/src/cxx/libraries/prime 
> > -I/build/prime-phylo-1.0.11/src/cxx/libraries/prime 
> > -I/usr/lib/x86_64-linux-gnu/openmpi/include/openmpi 
> > -I/usr/lib/x86_64-linux-gnu/openmpi/include -I/usr/  
> > lib/x86_64-linux-gnu/openmpi/include/ompi/mpi/cxx -I/usr/include/libxml2 
> > -I/build/prime-phylo-1.0.11/src/cxx/libraries 
> > -I/usr/lib/x86_64-linux-gnu/openmpi/include/openmpi/ompi/mpi/cxx 
> > -I/usr/lib/openmpi/include/openmpi/ompi/mpi/cxx  -g -O2 
> > -fdebug-prefix-map=/build/prime-phylo-1.0.11=. -fstack-protector-strong 
> > -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -
> > Wreorder -Wall -fexceptions -g -fPIC   -std=gnu++98 -o 
> > CMakeFiles/prime-phylo.dir/TreeInputOutput.cc.o -c 
> > /build/prime-phylo-1.0.11/src/cxx/libraries/prime/TreeInputOutput.cc
> 
> > /usr/include/unicode/umachine.h:347:13: error: 'char16_t' does not name a 
> > type; did you mean 'wchar_t'?
> ICU since 59 requires C++11 while your software uses -std=gnu++98.

Otherwise you can just define it. See e.g.

https://cgit.freedesktop.org/libreoffice/core/diff/configure.ac?id=fabad007c60958f2ff87e8f636ff6a798ad1f963

+if test "$ICU_MAJOR" -ge "59"; then
+# As of ICU 59 it defaults to typedef char16_t UChar; which is
available
+# with -std=c++11 but not all external libraries can be built with
that,
+# for those use a bit-compatible typedef uint16_t UChar; see
+# icu/source/common/unicode/umachine.h
+ICU_UCHAR_TYPE="-DUCHAR_TYPE=uint16_t"
+else
+ICU_UCHAR_TYPE=""
+fi

(but yes, projects using -std=c++11 don't need it.)

Regards,

Rene

Bug#898937: ITP: hunspell-lv -- Latvian dictionary for hunspell spellchecker

[Rene Engelhard]

On Thu, May 17, 2018 at 05:01:09PM +0200, Agustin Martin wrote:
> This dictionary contains Latvian wordlists for the hunspell
> spellchecker currently supported by Mozilla and OpenOffice,
> plus a Latvian hyphenation pattern for OpenOffice.
> 
> These sources will create a hunspell-lv binary package that will replace
> myspell-lv binary package. However, current myspell-lv sources will stay and
> will still be used to create the Latvian aspell dictionary package.

And it should create a hyphen-lv.

Regards,

Rene

Bug#898788: libreoffice-help-common: [RC] embedded copy of normalize.css

[Rene Engelhard]

Hi,

On Tue, May 15, 2018 at 10:56:25PM +0200, Rene Engelhard wrote:
> Which package? Don't see a package shipping it?

#898789 suggests libjs-normalize.css. Which doesn't exist.

Regards,

Rene

Bug#898788: libreoffice-help-common: [RC] embedded copy of normalize.css

[Rene Engelhard]

severity 898788 important
retitle 898788 libreoffice-help-common: embedded copy of normalize.css
thanks

Hi,

On Tue, May 15, 2018 at 10:39:44PM +0200, Bastien ROUCARIÈS wrote:
> Package: libreoffice-help-common
> Version: 1:6.1.0~beta1~git20180507-1
> Severity: serious
> Justification: Policy 4.13

Debian policy 4.13 says "should", not "must". I'd agree with you if this
was non-free, it isn't, though:

rene@frodo:~/data/git/LibreOffice/master/helpcontent2$ head -n 1
./help3xsl/normalize.css
/*! normalize.css v8.0.0 | MIT License |
 * github.com/necolas/normalize.css */

And why are the other ones not RC buggy? Why is chromium
not RC buggy? Why not texlive including poppler? etc.

This is at most important.

> This package include embedded copy of normalize.css
> /usr/share/libreoffice/help/normalize.css
> 
> Please use the package instead to use local copy

Which package? Don't see a package shipping it?

# apt-file search normalize.css
cargo-doc: /usr/share/doc/cargo-doc/doc/normalize.css
coffeescript-doc:
/usr/share/doc/coffeescript/html/annotated-source/public/stylesheets/normalize.css
glances:
/usr/lib/python3/dist-packages/glances/outputs/static/css/normalize.css
grafana-data: /usr/share/grafana/missing-sources/normalize.css
grafana-data: /usr/share/grafana/missing-sources/normalize.css.url
icingaweb2: /usr/share/icingaweb2/public/css/vendor/normalize.css
ldap-account-manager:
/usr/share/ldap-account-manager/style/responsive/105_normalize.css
libreoffice-help-common: /usr/share/libreoffice/help/normalize.css
r-cran-shiny:
/usr/lib/R/site-library/shiny/www/shared/ionrangeslider/css/normalize.css
recon-ng: /usr/share/recon-ng/recon/core/web/static/normalize.css
rust-doc: /usr/share/doc/rust-doc/html/normalize.css
rust-src: /usr/src/rustc-1.24.1/src/librustdoc/html/static/normalize.css
rust-src: /usr/src/rustc-1.25.0/src/librustdoc/html/static/normalize.css
sympa:
/usr/share/sympa/static_content/external/foundation/css/normalize.cs

I don't see a package shipping it?

Regards,

Rene