Re: minutes of ESC call ...

[Stephan Bergmann]

On 14/12/2022 13:19, Stephan Bergmann wrote:

On 02/03/2012 15:45, Stephan Bergmann wrote:
I've never given much thought to dynamic_cast vs. XUnoTunnel (at least 
I don't remember right now I ever did; searching old mail archives 
would probably prove me wrong) -- to me XUnoTunnel was always that 
rarely needed hack where the notational overhead doesn't really hurt.  
But sure, for the UNO wrappers in the application layers things look 
different.  Anyway, thinking about it now, I see no reason one could 
not use dynamic_cast instead of XUnoTunnel in the scenario outlined 
above.


Took me ten years to find the reason again why XUnoTunnel cannot be 
replaced with dynamic_cast, in general.  :)  See 
 "New loplugin:unocast": 
  "Find uses of dynamic_cast that cast from a UNO interface type. Unless 
it is known that the dynamic_cast must succeed, it can cause a crash:  
If the source object is a proxy from the C++ UNO bridge, its vtable's 
RTTI slot will normally not be set up (see e.g. the 
ENABLE_RUNTIME_OPTIMIZATIONS code in 
bridges::cpp_uno::shared::VtableFactory::initializeBlock in 
bridges/source/cpp_uno/gcc3_linux_x86-64/cpp2uno.cxx)."


...but 
 
"Rudimentary support for dynamic_cast on UNO proxy objects" to the rescue :)

Re: minutes of ESC call ...

[Stephan Bergmann]

On 02/03/2012 15:45, Stephan Bergmann wrote:
I've never given much thought to dynamic_cast vs. XUnoTunnel (at least I 
don't remember right now I ever did; searching old mail archives would 
probably prove me wrong) -- to me XUnoTunnel was always that rarely 
needed hack where the notational overhead doesn't really hurt.  But 
sure, for the UNO wrappers in the application layers things look 
different.  Anyway, thinking about it now, I see no reason one could not 
use dynamic_cast instead of XUnoTunnel in the scenario outlined above.


Took me ten years to find the reason again why XUnoTunnel cannot be 
replaced with dynamic_cast, in general.  :)  See 
 "New loplugin:unocast": 
 "Find uses of dynamic_cast that cast from a UNO interface type. 
Unless it is known that the dynamic_cast must succeed, it can cause a 
crash:  If the source object is a proxy from the C++ UNO bridge, its 
vtable's RTTI slot will normally not be set up (see e.g. the 
ENABLE_RUNTIME_OPTIMIZATIONS code in 
bridges::cpp_uno::shared::VtableFactory::initializeBlock in 
bridges/source/cpp_uno/gcc3_linux_x86-64/cpp2uno.cxx)."

Re: Saving documents with broken zip streams (Re: minutes of ESC call ...)

[Luboš Luňák]

On Friday 07 of June 2019, Wols Lists wrote:
> On 07/06/19 10:07, Luboš Luňák wrote:
> >> For what its worth those sample documents are not "realworld" user
> >> documents, but the output of fuzzing engines so any non-catastrophic
> >> outcome is acceptable IMO
> >
> >  I have avoided the assert with https://gerrit.libreoffice.org/#/c/73646/
> > . Given that it's (hopefully) very unlikely to find real documents with
> > broken zip internals, I find that good enough.
>
> Bear in mind I don't know the background to this ...
>
> My immediate reaction was "we can't refuse to let the user save their
> document, so could we disable 'save' and do a 'save as'?".

 That doesn't make a difference here. The code can't save such a broken 
document, period. Regardless of where it is being saved to.

> As for unlikely to find broken documents, it's too long ago for me to
> remember the details, but I remember salvaging a broken calc document by
> unzipping it and recovering the data portion. So real-world broken
> documents do happen (although I think in this case it was broken such
> that LO refused to open it ...)

 Manually unzipping and zipping back properly would work here too. Or you can 
improve the saving code to cope with such problems somehow, feel free to.

-- 
 Luboš Luňák
 l.lu...@collabora.com
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Saving documents with broken zip streams (Re: minutes of ESC call ...)

[Wols Lists]

On 07/06/19 10:07, Luboš Luňák wrote:
> On Thursday 06 of June 2019, Caolán McNamara wrote:
>> On Mon, 2019-06-03 at 21:52 +0200, Luboš Luňák wrote:
>>> Any idea what to do about that? Is it really ok that we just refuse
>>> to save it? Or should we save it even though the contents may be
>>> broken?
>>
>> For what its worth those sample documents are not "realworld" user
>> documents, but the output of fuzzing engines so any non-catastrophic
>> outcome is acceptable IMO
> 
>  I have avoided the assert with https://gerrit.libreoffice.org/#/c/73646/ . 
> Given that it's (hopefully) very unlikely to find real documents with broken 
> zip internals, I find that good enough.
> 
Bear in mind I don't know the background to this ...

My immediate reaction was "we can't refuse to let the user save their
document, so could we disable 'save' and do a 'save as'?".

As for unlikely to find broken documents, it's too long ago for me to
remember the details, but I remember salvaging a broken calc document by
unzipping it and recovering the data portion. So real-world broken
documents do happen (although I think in this case it was broken such
that LO refused to open it ...)

Cheers,
Wol
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Saving documents with broken zip streams (Re: minutes of ESC call ...)

[Luboš Luňák]

On Thursday 06 of June 2019, Caolán McNamara wrote:
> On Mon, 2019-06-03 at 21:52 +0200, Luboš Luňák wrote:
> > Any idea what to do about that? Is it really ok that we just refuse
> > to save it? Or should we save it even though the contents may be
> > broken?
>
> For what its worth those sample documents are not "realworld" user
> documents, but the output of fuzzing engines so any non-catastrophic
> outcome is acceptable IMO

 I have avoided the assert with https://gerrit.libreoffice.org/#/c/73646/ . 
Given that it's (hopefully) very unlikely to find real documents with broken 
zip internals, I find that good enough.

-- 
 Luboš Luňák
 l.lu...@collabora.com
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Saving documents with broken zip streams (Re: minutes of ESC call ...)

[Caolán McNamara]

On Mon, 2019-06-03 at 21:52 +0200, Luboš Luňák wrote:
> Any idea what to do about that? Is it really ok that we just refuse
> to save it? Or should we save it even though the contents may be
> broken?

For what its worth those sample documents are not "realworld" user
documents, but the output of fuzzing engines so any non-catastrophic
outcome is acceptable IMO

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Saving documents with broken zip streams (Re: minutes of ESC call ...)

[Luboš Luňák]

On Monday 03 of June 2019, Jan-Marek Glogowski wrote:
> Am 03.06.19 um 21:52 schrieb Luboš Luňák:
> >  Ok, so it's not a problem with my code, my changes just happened to show
> > the problem, and the problem is that those documents are broken. If you
> > try to unzip the documents, it will complain about incorrect CRC
...
> >  Any idea what to do about that? Is it really ok that we just refuse to
> > save it? Or should we save it even though the contents may be broken?
>
> IMHO the only sane solution would be to detect the broken CRCs on read and
> report a broken file to the user.

 That's not so easy. We do not detect broken CRCs on load, because we load on 
demand. And removing that seems like a bad trade-off. Finding that a CRC 
stream has a broken CRCs means uncompressing everything and checking, even 
things we otherwise do not care about. I think we do not want to make loading 
of everything possibly slower just to detect that virtually all documents are 
correct.

-- 
 Luboš Luňák
 l.lu...@collabora.com
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Saving documents with broken zip streams (Re: minutes of ESC call ...)

[Jan-Marek Glogowski]

Am 03.06.19 um 21:52 schrieb Luboš Luňák:
> On Monday 03 of June 2019, Caolán McNamara wrote:
>> On Mon, 2019-06-03 at 12:23 +0200, Luboš Luňák wrote:
>>> On Thursday 30 of May 2019, Michael Meeks wrote:
   + some in the zip area - assuming they are threading related.
>>>
>>>  Is this about those documents such
>>> as /srv/crashtestdata/files/caolan/opendocument_stack_overflow_2.odt
>>> ? How
>>> can I reproduce that problem? If I try to fetch
>>> buildsl...@vm138.documentfoundation.org:
>>> an/opendocument_stack_overflow_2.odt ,
>>> it doesn't exist.
>>
>> I attach two of the examples here. The input name was foo.sample, the
>> output to odt name appears higher up in the bt during the export.
>>
>> ./instdir/program/soffice.bin --headless --convert-to odt
>> opendocument_stack_overflow.sample
> 
> 
>  Ok, so it's not a problem with my code, my changes just happened to show the 
> problem, and the problem is that those documents are broken. If you try to 
> unzip the documents, it will complain about incorrect CRC (although it still 
> will uncompress them). And what happens is that when we try to save the file, 
> apparently only by that point we'll read those zip streams, there will be a 
> ZipException about that, and the code in package/ is not exception-safe. So 
> ZipOutputStream::writeLOC() gets called but not the matching 
> ZipOutputStream::rawCloseEntry().
> 
>  But this is actually broken on several levels. If I make the code to catch 
> the exception better, I'll need to make it somehow handle the fact that 
> writeLOC() prepared for writing en entry, but then there's nothing to write. 
> But that's actually not important, since ZipPackageStream::saveChild() will 
> still return failure, so ZipPackageFolder::saveContents() will throw an 
> exception, making the whole document saving fail. Which in turn means this 
> whole save business is irrelevant, as there's just no way to save the 
> document, even though we can load it and we can edit it. Which seems rather 
> lame.
> 
>  Any idea what to do about that? Is it really ok that we just refuse to save 
> it? Or should we save it even though the contents may be broken?

IMHO the only sane solution would be to detect the broken CRCs on read and
report a broken file to the user. Eventually we could offer some recovery
option: mark the broken CRCs to be recalculated and keep the stuff or drop the
broken ZIP entries. I guess most users can't make this decision, so I would opt
for optional recovery of the entries, ignoring the CRCs.

Easier solution: we just deny / abort loading the file and tell the user babout
the broken file.

It really strange that the broken CRCs are just detected on write and the
document loads without a problem. Or do we ignore all ZIP entries, which we
don't know, which would be strange too?
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Saving documents with broken zip streams (Re: minutes of ESC call ...)

[Luboš Luňák]

On Monday 03 of June 2019, Caolán McNamara wrote:
> On Mon, 2019-06-03 at 12:23 +0200, Luboš Luňák wrote:
> > On Thursday 30 of May 2019, Michael Meeks wrote:
> > >   + some in the zip area - assuming they are threading related.
> >
> >  Is this about those documents such
> > as /srv/crashtestdata/files/caolan/opendocument_stack_overflow_2.odt
> > ? How
> > can I reproduce that problem? If I try to fetch
> > buildsl...@vm138.documentfoundation.org:
> > an/opendocument_stack_overflow_2.odt ,
> > it doesn't exist.
>
> I attach two of the examples here. The input name was foo.sample, the
> output to odt name appears higher up in the bt during the export.
>
> ./instdir/program/soffice.bin --headless --convert-to odt
> opendocument_stack_overflow.sample


 Ok, so it's not a problem with my code, my changes just happened to show the 
problem, and the problem is that those documents are broken. If you try to 
unzip the documents, it will complain about incorrect CRC (although it still 
will uncompress them). And what happens is that when we try to save the file, 
apparently only by that point we'll read those zip streams, there will be a 
ZipException about that, and the code in package/ is not exception-safe. So 
ZipOutputStream::writeLOC() gets called but not the matching 
ZipOutputStream::rawCloseEntry().

 But this is actually broken on several levels. If I make the code to catch 
the exception better, I'll need to make it somehow handle the fact that 
writeLOC() prepared for writing en entry, but then there's nothing to write. 
But that's actually not important, since ZipPackageStream::saveChild() will 
still return failure, so ZipPackageFolder::saveContents() will throw an 
exception, making the whole document saving fail. Which in turn means this 
whole save business is irrelevant, as there's just no way to save the 
document, even though we can load it and we can edit it. Which seems rather 
lame.

 Any idea what to do about that? Is it really ok that we just refuse to save 
it? Or should we save it even though the contents may be broken?

-- 
 Luboš Luňák
 l.lu...@collabora.com
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: minutes of ESC call ...

[Michael Weghorn]

Hi everyone,

a quick follow-up:

> * Pending Action Items:
> + run the certification script (Kendy)
> + make Qt5 backend experimental (Jmux)

Just talked to jmux on IRC. Since making qt5 experimental doesn't work
easily (s. Jan-Marek's email [1]), the suggestion is to just keep it as
is, i.e. qt5 is never used by default, but people can select it by
setting the SAL_USE_VCLPLUGIN=qt5 environment  variable (and set
SAL_VCL_QT5_USE_CAIRO in addition to get Cairo rendering).

This is the third option from the 3 Jan-Marek suggested:
> IMHO that leaves us with:
> 1. don't allow to load the qt5 plugin in 6.2 at all
> 2. switch qt5 to cairo in 6.2 only
> 3. cope with the eventual bug fallout, when 6.2 becomes still (which I think
> won't be large, but who knows)


[1] https://lists.freedesktop.org/archives/libreoffice/2019-May/082835.html



signature.asc
Description: OpenPGP digital signature
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: minutes of ESC call ...

[Michael Weghorn]

On 23/05/2019 17.19, Jan-Marek Glogowski wrote:
> IMHO that leaves us with:
> 1. don't allow to load the qt5 plugin in 6.2 at all
> 2. switch qt5 to cairo in 6.2 only
> 3. cope with the eventual bug fallout, when 6.2 becomes still (which I think
> won't be large, but who knows)
> 
> Honestly I would go with 3. Eventually even 2.

Sounds reasonable to me (both, 3. and 2.).
> P.S. and if kde5 doesn't make it into still, qt5 will be gone too.

That depends. My understanding of the discussion so far (s.a.
tdf#124044) was that kde5 wouldn't be the default (on Plasma/LXQt) if
not considered "ready" in time for 6.2.5. This could e.g. easily be
achieved by reverting commit f2bf002e90bf5cc74cf190d66507e59b78ba73e9
("Add autodetection for KDE5 VCL Plugin").
In this case, people manually setting "SAL_USE_VCLPLUGIN" would still be
able to choose qt5 or kde5, but IMHO people doing so should know what
they're doing... (matching case 3 from above).
I don't have strong opinion on that, though.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: minutes of ESC call ...

[Jan-Marek Glogowski]

Hi everyone,

Am 23.05.19 um 16:34 schrieb Michael Meeks:
> * Completed Action Items:
> 
> * Pending Action Items:
> + make Qt5 backend experimental (Jmux)

So I just tried to implement this, but it's to early to access the config.
I get an com::sun::star::uno::DeploymentException when using
officecfg::Office::Common::Misc::ExperimentalMode::get() and the "real"
SvtMiscOptions::IsExperimentalMode() is in svtools, which itself depends on vcl,
so I can't use that either.

I really don't want to start parsing LO config options in some manual way in the
plugin loader. I was hoping for a simple solution (two lines of code currently),
but here we are / I am.

IMHO that leaves us with:
1. don't allow to load the qt5 plugin in 6.2 at all
2. switch qt5 to cairo in 6.2 only
3. cope with the eventual bug fallout, when 6.2 becomes still (which I think
won't be large, but who knows)

Honestly I would go with 3. Eventually even 2.

Something for next week?
Other opinions and options?

Jan-Marek

P.S. and if kde5 doesn't make it into still, qt5 will be gone too.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Jenkins build times (Re: minutes of ESC call ...)

[Luboš Luňák]

On Saturday 18 of May 2019, Luboš Luňák wrote:
> On Friday 17 of May 2019, Thorsten Behrens wrote:
> > Yeah, same anecdotal evidence here. Is the assumption we don't need
> > more Mac build power based on hard data?
>
>  IIRC one Mac bot had some problems a couple of days back, so maybe the
> increased Mac load was just caused by catching up there (I certainly
> remember waiting for those to finally pass). If I right now look at gerrit
> master builds in progress, none of them is currently waiting exclusively
> for Mac, but some of them are for Windows.


 BTW, I've noticed that all setups except for gcc use --enable-dbgutil, which 
in turn by default does --disable-optimized. Given that Jenkins builds also 
run all checks and that takes time that cannot be avoided/cached in any way, 
wouldn't it be in total faster to go with --enable-optimized? I'm not sure 
how that'd turn out with the Windows build, but at least the ccache-enabled 
ones could easily gain on that. I know unittests also try to print out a 
backtrace if they crash, but do we need that for Jenkins builds? Quite 
possibly adding --enable-optimized --disable-symbols could save quite some 
build power.

 Also, every build has to build all the stuff in external/, over and over 
again. That shouldn't matter much with ccache, but presumably the Windows 
build spends quite some time there. We could try some silly^H^Hinteresting 
improvements there, such as adding PCHs even for those.

-- 
 Luboš Luňák
 l.lu...@collabora.com
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: minutes of ESC call ...

[Noel Grandin]

On Sat, 18 May 2019 at 12:15, Luboš Luňák  wrote:

> On Friday 17 of May 2019, Thorsten Behrens wrote:
> > Stephan Bergmann wrote:
> > > Whenever I recently happened to look at Gerrit/Jenkins builds that
> > > hadn't finished yet, it was the Mac build that was still
> > > outstanding, so I think we do have a bottleneck there after all.
> >
> > Yeah, same anecdotal evidence here. Is the assumption we don't need
> > more Mac build power based on hard data?
>

Periodically the mac build bots maintained by Norbert will go offline or
become unreachable and that can take a couple of days to resolve, and once
they come back the build queue can take a day or so to get back to normal.

If we want more reliability, we are going to need more mac resources hosted
where we can get to them faster.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: minutes of ESC call ...

[Luboš Luňák]

On Friday 17 of May 2019, Thorsten Behrens wrote:
> Stephan Bergmann wrote:
> > Whenever I recently happened to look at Gerrit/Jenkins builds that
> > hadn't finished yet, it was the Mac build that was still
> > outstanding, so I think we do have a bottleneck there after all.
>
> Yeah, same anecdotal evidence here. Is the assumption we don't need
> more Mac build power based on hard data?


 IIRC one Mac bot had some problems a couple of days back, so maybe the 
increased Mac load was just caused by catching up there (I certainly remember 
waiting for those to finally pass). If I right now look at gerrit master 
builds in progress, none of them is currently waiting exclusively for Mac, 
but some of them are for Windows.


-- 
 Luboš Luňák
 l.lu...@collabora.com
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: minutes of ESC call ...

[Thorsten Behrens]

Stephan Bergmann wrote:
> Whenever I recently happened to look at Gerrit/Jenkins builds that
> hadn't finished yet, it was the Mac build that was still
> outstanding, so I think we do have a bottleneck there after all.
>
Yeah, same anecdotal evidence here. Is the assumption we don't need
more Mac build power based on hard data?

Cheers,

-- Thorsten


signature.asc
Description: PGP signature
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: minutes of ESC call ...

[Stephan Bergmann]

On 09/05/2019 16:46, Michael Meeks wrote:

* Jenkins / CI update (Christian)
 from:Thu May  2 13:58:26 2019
 master linux rel  jobs: 129 ok: 129 ko:   0 fail ratio:  0.00 % break:   0 
broken duration: 0.00%
 master linux dbg  jobs:  86 ok:  83 ko:   3 fail ratio:  3.49 % break:   2 
broken duration: 4.03%
 master mac reljobs:  75 ok:  70 ko:   5 fail ratio:  6.67 % break:   4 
broken duration: 5.67%
 master mac dbgjobs:  69 ok:  62 ko:   7 fail ratio: 10.14 % break:   4 
broken duration:12.32%
 master win reljobs:  86 ok:  63 ko:  23 fail ratio: 26.74 % break:  17 
broken duration:23.09%
 master win dbgjobs:  90 ok:  75 ko:  15 fail ratio: 16.67 % break:  12 
broken duration:12.80%
 master win64 dbg  jobs:  88 ok:  67 ko:  21 fail ratio: 23.86 % break:  16 
broken duration:25.91%
 lo-5.3 macjobs:   0 ok:   0 ko:   0 fail ratio:  0.00 % break:   0 
broken duration: 0.00%
 lo-5.4 macjobs:   0 ok:   0 ko:   0 fail ratio:  0.00 % break:   0 
broken duration: 0.00%
 master gerrit lin jobs: 451 ok: 331 ko:  21 fail ratio:  4.66% time for 
ok: mean:  21 median:  21
 master gerrit plg jobs: 462 ok: 297 ko:  92 fail ratio: 19.91% time for 
ok: mean:  36 median:  33
 master gerrit win jobs: 498 ok: 292 ko:  75 fail ratio: 15.06% time for 
ok: mean:  65 median:  64
 master gerrit mac jobs: 478 ok: 291 ko:  74 fail ratio: 15.48% time for 
ok: mean:  62 median:  37
 master gerrit all jobs: 434 ok: 240 ko: 165 fail ratio: 38.02% time for 
ok: mean: 120 median:  85
+ https://dev-www.libreoffice.org/tmp/gerrit_190509.html
+ notable test failures in last seven days:
   4 JunitTest_forms_unoapi_2
   5 UITest_conditional_format
   7 CppunitTest_sc_bugfix_test
  11 UITest_writer_tests5
+ dis-connected bots over the weekend
+ one failing mac killed a lot of builds until disabled
+ 2 Mac Pros dis-connected, one mis-behaving, one in power-save state ?
   + right now – 1 Mac short.
   + 1 is at Norbert’s company – needs an ask for a reboot, or re-route
+ could we get another Mac Pro for hosting ? (Thorsten)
   + hard to host – but no mounting for racks (Christian)
  + newer Mac Minis are perhaps suitable.
   + Macs shouldn’t be the bottleneck anyway
   + Windows is the limiting factor


Whenever I recently happened to look at Gerrit/Jenkins builds that 
hadn't finished yet, it was the Mac build that was still outstanding, so 
I think we do have a bottleneck there after all.


Witness:

* My "May 16 22:51" comment at 
: "gerrit_mac is hopelessly 
overloaded right now, with a 30+ long build queue (waiting builds #33071 
through #33095)" (though that's rather 20+ than 30+, of course)


* Armin's "May 16 23:32" comment at 
: "sooo... Build is blocked 
prob due to Mac missing - due to no Macs available...?"

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: minutes of ESC call ...

[Noel Grandin]

On Thu, 16 May 2019 at 17:04, Michael Meeks 
wrote:

> * ItemSet re-work (Armin)
>+ most of items are sorted in the item-pools (Armin)
>   + not inside the item-sets.
>   + in the item pools: just in a vector
>   + only compare, not < operator – usually not sorted.
>

Note that I have recently, as part of performance work, added the ability
for SfxPoolItem's to opt-in to sorting themselves when stored inside
SfxItemPool, which dramatically speeds up the common "lets see if the item
already exists in this pool" check.


https://opengrok.libreoffice.org/xref/core/svl/source/inc/poolio.hxx?r=0725e8a5


https://opengrok.libreoffice.org/xref/core/include/svl/poolitem.hxx?r=1e268223#154
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: minutes of ESC call ...

[Xisco Fauli]

Hi Michael,

El 18/4/19 a les 16:55, Michael Meeks ha escrit:
> + UI testing tool update ?
>   + Code is in 
> https://cgit.freedesktop.org/libreoffice/contrib/dev-tools/tree/uitest/mass-testing
>   + Calc: Found some crashes related to the dynamic number of columns work
>   - E.g. 
> https://bugs.documentfoundation.org/show_bug.cgi?id=124818
>   - Noel fixing them
>   + Writer: Many files crashing with paste + undo
>   - Mostly related to 
>   https://bugs.documentfoundation.org/show_bug.cgi?id=117215
> + inherited from OpenOffice
>   - 13800 crashes in crashreport of this signature → 
> https://crashreport.libreoffice.org/stats/signature/BigPtrArray::Index2Block(unsigned%20long)
> + what is a big number for traces ? (Michael)
>+ difficult to tell (Xisco)
>   + don’t know in total; think it’s a big #
>   + tested 2500 files, and 30 crash.

I've just remembered we can retrieve the total number of crashes from
the crashreport API [1], so the crash mentioned above represents the 0.3
of the total

Regards

[1] http://crashreport.libreoffice.org/api/get/crash-count

-- 
Xisco Faulí
Libreoffice QA Team
IRC: x1sc0

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: minutes of ESC call ...

[Michael Weghorn]

On 05/04/2019 11.06, Xisco Fauli wrote:
> Just to clarify,
> https://bugs.documentfoundation.org/show_bug.cgi?id=124039 ( listed
> already as Most Pressing Bug ) and the bug mentioned by Oliver have the
> same root cause. Jan-Marek closed one as duplicate of the other.

A big thanks to Mike Kaganski and Jan-Marek for looking into this and
their cooperation in providing a fix so quickly!



signature.asc
Description: OpenPGP digital signature
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: minutes of ESC call ...

[Xisco Fauli]

Hello,

Just to clarify,
https://bugs.documentfoundation.org/show_bug.cgi?id=124039 ( listed
already as Most Pressing Bug ) and the bug mentioned by Oliver have the
same root cause. Jan-Marek closed one as duplicate of the other.

Regards

El 4/4/19 a les 18:12, Oliver Brinzing ha escrit:
> Hi,
>
>>  + 6.1.6 rc1: April 9 next week >  + Most pressing bugs:
> Could someone please take a look at issue
>
> crash: use of "com.sun.star.ui.dialogs.FolderPicker" service from java
> seems to cause crashes
> https://bugs.documentfoundation.org/show_bug.cgi?id=123502
>
> it affects windows 7/10 and is reproducible with LO 6.1.5.2 but not
> with LO 6.1.4.2.
>
> Regards
> Oliver
> ___
> LibreOffice mailing list
> LibreOffice@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/libreoffice

-- 
Xisco Faulí
Libreoffice QA Team
IRC: x1sc0

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: minutes of ESC call ...

[Oliver Brinzing]

Hi,


 + 6.1.6 rc1: April 9 next week >  + Most pressing bugs:

Could someone please take a look at issue

crash: use of "com.sun.star.ui.dialogs.FolderPicker" service from java seems to 
cause crashes
https://bugs.documentfoundation.org/show_bug.cgi?id=123502

it affects windows 7/10 and is reproducible with LO 6.1.5.2 but not with LO 
6.1.4.2.

Regards
Oliver
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: minutes of ESC call ...

[Michael Meeks]

Hi Markus,

On 06/12/2018 16:46, Markus Mohrhard wrote:
>          + minor complaint wrt. single Chart save removal in calc
> (Heiko)
>             + how to know ? - checkout release notes
>  
> These people should feel free to complain to me. However the removal was
> necessary and long overdue. Actually, the feature was responsible for
> many regressions and was originally intended by me for debugging purposes.

Amusing =) Heiko would know those involved I guess.

> perftest is not running on gandalf, instead on vm139. 
> 
> As I'm one of the main users of gandalf (e.g. update, UI testing, random
> config) and some more exotic builds not managed by jenkins I will try to
> take care of the update during the weekend.

Thanks so much for that ! seems like that one machine does a lot.

ATB,

Michael.

-- 
michael.me...@collabora.com <><, GM Collabora Productivity
Hangout: mejme...@gmail.com, Skype: mmeeks
(M) +44 7795 666 147 - timezone usually UK / Europe
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: minutes of ESC call ...

[Markus Mohrhard]

Hey all,

On Thu, Dec 6, 2018 at 4:31 PM Michael Meeks 
wrote:

>  + minor complaint wrt. single Chart save removal in calc (Heiko)
> + how to know ? - checkout release notes
>
>

These people should feel free to complain to me. However the removal was
necessary and long overdue. Actually, the feature was responsible for many
regressions and was originally intended by me for debugging purposes.


> * Tinderbox bits (Stephan)
> + gandalf – too old compiler; keeps failing tinderboxen
>+ bit of a problem, needs SUSE goodwill to help us connect a
> console etc.
>+ can we not live-upgrade it ? (Thorsten)
>+ just needs a new gcc (Stephan)
>   + some SLES12 there – with internal repos etc. (Thorsten)
>  + in some odd state there.
>+ not eager to touch it unless we can afford to loose it (Thorsten)
> + rsync some container or other onto there ?
> + what jobs run there ? (Thorsten)
>+ lcov, perftest(?), random config,
>  UI testing, update, UI testing (Stephan, Christian)
>+ can we move jobs off it ?
>   + unclear if they have extra build deps ? (Christian)
>  + perhaps more sustainable to migrate this (Thorsten)
> + poke Guilhelm → to poke admins (Christian)
>


perftest is not running on gandalf, instead on vm139.

As I'm one of the main users of gandalf (e.g. update, UI testing, random
config) and some more exotic builds not managed by jenkins I will try to
take care of the update during the weekend. I already managed to get gperf
working but the SUSE network firewall blocks access to github so flex could
not be updated. The new compiler should be possible without major issues.

Regards,
Markus
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Minutes of ESC call: 2018-08-02

[Noel Grandin]

On 2018/08/06 11:06 AM, Michael Stahl wrote:

On 02.08.2018 20:25, Jan Holesovsky wrote:

    + tests that failed more than twice in last 7 days:
   3 CppunitTest_sw_filters_test
   3 CppunitTest_sw_htmlimport
   3 CppunitTest_vcl_complextext
   3 CppunitTest_vcl_fontfeature
   4 CppunitTest_sw_uiwriter
   5 CppunitTest_vcl_pdfexport


i've enabled some verbose logging code in WNT font initialisation to track down the CppunitTest_vcl_fontfeature 
failures; can this logging be disabled again now?


i'm unable to find one of these 3 failed build logs now to see if they are perhaps all based on some ancient master, but 
probably it is available somewhere inside Jenkins if one knows where to look ...



My apologies, I did not realise you were actually looking at solving that, I have been steadily trimming the vcl font 
feature unit test until it stopped causing jenkins issues, see commits


   415436ad27b4522102d3fbbb6003935871029fc6

   fadd8727cd050c00af4f0986626b99a9e84f1ddd

   180fa02a592bc846e21e3d58c548e6ed7c7039d5
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Minutes of ESC call: 2018-08-02

[Michael Stahl]

On 06.08.2018 11:06, Michael Stahl wrote:

On 02.08.2018 20:25, Jan Holesovsky wrote:

    + tests that failed more than twice in last 7 days:
   3 CppunitTest_sw_filters_test
   3 CppunitTest_sw_htmlimport
   3 CppunitTest_vcl_complextext
   3 CppunitTest_vcl_fontfeature
   4 CppunitTest_sw_uiwriter
   5 CppunitTest_vcl_pdfexport


i've enabled some verbose logging code in WNT font initialisation to 
track down the CppunitTest_vcl_fontfeature failures; can this logging be 
disabled again now?


i'm unable to find one of these 3 failed build logs now to see if they 
are perhaps all based on some ancient master, but probably it is 
available somewhere inside Jenkins if one knows where to look ...


FWIW the 2 build logs that i could locate now with cloph's database dump 
are:


https://ci.libreoffice.org/job/gerrit_windows/12896/consoleFull

master parent: e119194aeec907f3d02cb914e5afde5ac763df7c <- this is very 
old and pre-dates any fixes


C:/cygwin/home/tdf/lode/jenkins/workspace/gerrit_windows/vcl/qa/cppunit/FontFeatureTest.cxx(66) 
: error : Assertion

Test name: FontFeatureTest::testGetFontFeatures
equality assertion failed
- Expected: 27
- Actual  : 20

https://ci.libreoffice.org/job/gerrit_windows/12500/consoleFull

master parent: 7ac4e48687d7679927f5659e941024445946ffa7 <- this includes 
both quikee's fixes and Noel's disabling of lots of the test in question...


C:/cygwin/home/tdf/lode/jenkins/workspace/gerrit_windows/vcl/qa/cppunit/FontFeatureTest.cxx(87) 
: error : Assertion

Test name: FontFeatureTest::testGetFontFeatures
equality assertion failed
- Expected: 1664250723
- Actual  : 1819178349

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Minutes of ESC call: 2018-08-02

[Michael Stahl]

On 02.08.2018 20:25, Jan Holesovsky wrote:

+ tests that failed more than twice in last 7 days:
   3 CppunitTest_sw_filters_test
   3 CppunitTest_sw_htmlimport
   3 CppunitTest_vcl_complextext
   3 CppunitTest_vcl_fontfeature
   4 CppunitTest_sw_uiwriter
   5 CppunitTest_vcl_pdfexport


i've enabled some verbose logging code in WNT font initialisation to 
track down the CppunitTest_vcl_fontfeature failures; can this logging be 
disabled again now?


i'm unable to find one of these 3 failed build logs now to see if they 
are perhaps all based on some ancient master, but probably it is 
available somewhere inside Jenkins if one knows where to look ...

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: minutes of ESC call ...

[Xisco Fauli]

Hello,

> + CRASH: Print Preview crashes on signed document without infobar
> + https://bugs.documentfoundation.org/show_bug.cgi?id=117426
> + Bubli (has fix for 5.4.x) band-aid ? …
> + asked wrt. cherry-picking to 6.0 (Xisco)
> + would prefer to have band-aid in 6.0 & 6.1 (Michael)
> + would prefer an ideal fix if possible (Thorsten)
>+ otherwise band-aid sounds sensible.
> => push the band-aid fix into 6.0 and 6.1 for now (Xisco)
>
>
Actually the band-aid fix is also in 6-0 and 6-1 branches:

- 8853067a29e091a230a6397bd7c100494ae9f5bf

- 43459bac67363f49aadd851e686d4a74b8ddc256

The reason why it's crashing in those branches and not in 5.4.7 is
e744e9f4492d3013742fcdb6254cd76528870e9d, so we either live with it and
wait for the fix or we revert it in those branches...

Regards

-- 
Xisco Faulí
Libreoffice QA Team
IRC: x1sc0


___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: minutes of ESC call ...

[Miklos Vajna]

Hi,

On Wed, Jul 11, 2018 at 05:22:01PM +0100, Michael Meeks 
 wrote:
> + Windows tinderbox/build-bot owners to parallel install VS2017

This is now required on master, if you admin a tinderbox that builds
master, then please make sure that VS2017 is installed.

If you have no time to install VS2017 now, please consider not building
master till you have the required toolchain.

(Jenkins slaves have it installed.)

Thanks,

Miklos


signature.asc
Description: Digital signature
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

RE: minutes of ESC call ...

[Kaganski Mike]

+ top 5 reviewers:
  Pootle bot made 2988 review comments in 1 month, and 2988 in 1 year

But was it awarded a t-shirt or something? :-)

--
Best regards,
Mike Kaganski
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Fwd: Re: [libreoffice-l10n] Fwd: Re: Minutes of ESC call 2017-07-05

[Sophia Schröder]

 Weitergeleitete Nachricht 
Betreff:Re: [libreoffice-l10n] Fwd: Re: Minutes of ESC call 2017-07-05
Datum:  Mon, 9 Jul 2018 20:06:01 +0200
Von:Sophia Schröder 
Organisation:   LibreOffice.org
An: l...@global.libreoffice.org



Hello Sophie, *,

the big workload of my 1st round of changes have just landed in Pootle
and I see the issues they caused.

Some of the the "improvements" I made turned out to not be
needed/helpful at al,
others introduces new inconsistencies.
And there are some new mistakes not neccessarily caused by me, but now
they are there.

My plan was to go through file for file in a more or less numerical order.

It seems to turn out not to be the best solution for the project.

If o.k., I could take the file(s) I just see a mistake in in Pootle.
Would that helps?


Am 09.07.2018 um 18:49 schrieb sophi:

Hi Sophia,

Le 07/07/2018 à 18:49, Sophia Schröder a écrit :

Sorry for the extra work, but... ;-) :-*

No problem, let see how we can try to find a compromise that could work
for you and for translators.


 Weitergeleitete Nachricht 
Betreff: Re: Minutes of ESC call 2017-07-05
Datum: Sat, 7 Jul 2018 18:44:56 +0200
Von: Sophia Schröder 
Organisation: LibreOffice.org
An: libreoffice@lists.freedesktop.org



* Documentation (Olivier)

  + New help
  + Testing in bug hunting session tomorrow (installs)
  + Small corrections in XSLT filter
  + tweaks in CSS by fitoshido – people start contributing
  + Help contents
  + cosmetic refactor by SophiaS
  + Contents for [NatNum12] by Lazlo Nemetz
  + Contents fixes (ohallot, fitoshido)
* l10n (Sophie)
 + gave feedback to Olivier on reformat patches – cosmetics changes
   not ideal for our l10n volunteers
 + better to also have actual help content changes alongside

I am with you. Please see my minor cosmetical changes as they are intented:
A ground work for further improvements and easier work with the help
files themselves.
And it is planned as a "Long Term Project" to not flood translators with
minor changes at once.

Let me explain it in one phrase as an example:

"Press the Enter key." - In this form, the plain text will be displayed
to our user.

But hey, we have also at least two other forms of this sentence:

"Press the Enter key.", which will display the word "Enter"
in bold.

And there is "Press the Enter key.", which
behaves like the second case for now.

But in the end, the last one let us play with more possibilities in css
styles, no? (I am not sure, just speculating).
I am thinking about an underlying background of a key, for example.

And yes, I am experimenting a bit here and there to find out best
solutions and practices.

So yes, carefull reviewings and criticisms are very welcome.

My proposal was to keep your work, but as part of a global rework of the
file, not as a unique change when it's about moving a period or some
spaces between two xml tags. Better, push the changes when a paragraph
or a sentence is modified or amended. That way there is no double work
for translators (or even triple if there is a typo in the new sentence
as it mays often happen due to the difficulty to work in the middle of
xml files).

I am not quite sure, what you mean. Can you explain it more, please?



And things like "Print icon" - l only say kerning and
spacing in the resulting text.

I would like to extend/expand help textes by the way, while also
reducing translation work by using the embedding feature instead of
translating the same sentence several times again, but honestly, I have
no clue how that works.

This could be difficult for translation because the meaning could be
different taking the context, grammar, gender and so on, into account.

Ah I see. So I do not longer bother. It is beyond my skills anyway for now.

I also changed my workflow to work file for file, hope that helps, at
least in my case for merge conflicts I cannot solve online, but also for
reviewing.

Maybe you could coordinate your work with others in the documentation
team and achieve the same work you are doing now but in the files they
are adding content to. That way, you continue working on what you want
and translators have only one time translation work on the same file.
Would you see that possible to organize with Olivier and would that be
convenient for you?

I wouldn't mind to improve my workflow in that way.
But I don't know how to achieve that, but open for discussions and
hopefully working solutions in that manner.


Cheers
Sophie



--
Regards / Mit freundlichen Grüßen

Sophia Schröder
---
www.LibreOffice.org
German Language Team
Help Files Debugger
IRC: SophiaS


--
To unsubscribe e-mail to: l10n+unsubscr...@global.libreoffice.org
Problems? https://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting 

Re: [libreoffice-l10n] Fwd: Re: Minutes of ESC call 2017-07-05

[sophi]

Hi Sophia,

Le 07/07/2018 à 18:49, Sophia Schröder a écrit :
> Sorry for the extra work, but... ;-) :-*

No problem, let see how we can try to find a compromise that could work
for you and for translators.

> 
>  Weitergeleitete Nachricht 
> Betreff: Re: Minutes of ESC call 2017-07-05
> Datum: Sat, 7 Jul 2018 18:44:56 +0200
> Von: Sophia Schröder 
> Organisation: LibreOffice.org
> An: libreoffice@lists.freedesktop.org
> 
> 
> 
> * Documentation (Olivier)
>>  + New help
>>  + Testing in bug hunting session tomorrow (installs)
>>  + Small corrections in XSLT filter
>>  + tweaks in CSS by fitoshido – people start contributing
>>  + Help contents
>>  + cosmetic refactor by SophiaS
>>  + Contents for [NatNum12] by Lazlo Nemetz
>>  + Contents fixes (ohallot, fitoshido)
>> * l10n (Sophie)
>> + gave feedback to Olivier on reformat patches – cosmetics changes
>>   not ideal for our l10n volunteers
>> + better to also have actual help content changes alongside
> 
> I am with you. Please see my minor cosmetical changes as they are intented:
> A ground work for further improvements and easier work with the help
> files themselves.
> And it is planned as a "Long Term Project" to not flood translators with
> minor changes at once.
> 
> Let me explain it in one phrase as an example:
> 
> "Press the Enter key." - In this form, the plain text will be displayed
> to our user.
> 
> But hey, we have also at least two other forms of this sentence:
> 
> "Press the Enter key.", which will display the word "Enter"
> in bold.
> 
> And there is "Press the Enter key.", which
> behaves like the second case for now.
> 
> But in the end, the last one let us play with more possibilities in css
> styles, no? (I am not sure, just speculating).
> I am thinking about an underlying background of a key, for example.
> 
> And yes, I am experimenting a bit here and there to find out best
> solutions and practices.
> 
> So yes, carefull reviewings and criticisms are very welcome.

My proposal was to keep your work, but as part of a global rework of the
file, not as a unique change when it's about moving a period or some
spaces between two xml tags. Better, push the changes when a paragraph
or a sentence is modified or amended. That way there is no double work
for translators (or even triple if there is a typo in the new sentence
as it mays often happen due to the difficulty to work in the middle of
xml files).

> 
> And things like "Print icon" - l only say kerning and
> spacing in the resulting text.
> 
> I would like to extend/expand help textes by the way, while also
> reducing translation work by using the embedding feature instead of
> translating the same sentence several times again, but honestly, I have
> no clue how that works.

This could be difficult for translation because the meaning could be
different taking the context, grammar, gender and so on, into account.
> 
> I also changed my workflow to work file for file, hope that helps, at
> least in my case for merge conflicts I cannot solve online, but also for
> reviewing.

Maybe you could coordinate your work with others in the documentation
team and achieve the same work you are doing now but in the files they
are adding content to. That way, you continue working on what you want
and translators have only one time translation work on the same file.
Would you see that possible to organize with Olivier and would that be
convenient for you?

Cheers
Sophie

-- 
Sophie Gautier sophie.gaut...@documentfoundation.org
GSM: +33683901545
IRC: sophi
Release coordinator
The Document Foundation
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Minutes of ESC call 2017-07-05

[Sophia Schröder]

* Documentation (Olivier)

 + New help
 + Testing in bug hunting session tomorrow (installs)
 + Small corrections in XSLT filter
 + tweaks in CSS by fitoshido – people start contributing
 + Help contents
 + cosmetic refactor by SophiaS
 + Contents for [NatNum12] by Lazlo Nemetz
 + Contents fixes (ohallot, fitoshido)
* l10n (Sophie)
+ gave feedback to Olivier on reformat patches – cosmetics changes
  not ideal for our l10n volunteers
+ better to also have actual help content changes alongside


I am with you. Please see my minor cosmetical changes as they are intented:
A ground work for further improvements and easier work with the help 
files themselves.
And it is planned as a "Long Term Project" to not flood translators with 
minor changes at once.


Let me explain it in one phrase as an example:

"Press the Enter key." - In this form, the plain text will be displayed 
to our user.


But hey, we have also at least two other forms of this sentence:

"Press the Enter key.", which will display the word "Enter" 
in bold.


And there is "Press the Enter key.", which 
behaves like the second case for now.


But in the end, the last one let us play with more possibilities in css 
styles, no? (I am not sure, just speculating).

I am thinking about an underlying background of a key, for example.

And yes, I am experimenting a bit here and there to find out best 
solutions and practices.


So yes, carefull reviewings and criticisms are very welcome.

And things like "Print icon" - l only say kerning and 
spacing in the resulting text.


I would like to extend/expand help textes by the way, while also 
reducing translation work by using the embedding feature instead of 
translating the same sentence several times again, but honestly, I have 
no clue how that works.


I also changed my workflow to work file for file, hope that helps, at 
least in my case for merge conflicts I cannot solve online, but also for 
reviewing.


Regards / Mit freundlichen Grüßen

Sophia Schröder
---
www.LibreOffice.org
German Language Team
Help Files Debugger
IRC: SophiaS

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: minutes of ESC call ...

[Khaled Hosny]

On Thu, Jun 21, 2018, 4:50 PM Michael Meeks 
wrote:

>+ Tools > Options > Asian/CTL always active
>+ https://bugs.documentfoundation.org/show_bug.cgi?id=104318


The issue (at least the recent comment that revived it) argues that
disabling CTL (and by extension CJK) by default makes it much harder for
users of these scripts to use LibreOffice (which is my experience as well,
we have many reports of users failing to use such basic functionality
because it was hidden by default). So the fix it to actually make sure the
controls are always visible and may remove the option to hide them
altogether, not hiding them by default.

If the dialogs are cluttered, then they need to be organized not hiding
basic UI needed by a large segment of our users.

   + e.g. in tabs with Tools > Options > Language Settings > Default on
> top
>+ remove “For the current document only”
>+ would be happy if some developer looked at this (Michael)
>   + ideally with CTL experience.
>+ makes it more complex for those who don’t know CTL (Cloph)
>+ lots of work showing these only when there are hints (Caolan)
>   + start in a US locale – CJK document, turned off …
>   + but if any settings on the system that suggest CJK
> should be enabled
>


Often than not such heuristics fails.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: minutes of ESC call ...

[Noel Grandin]

e

On 7 June 2018 at 16:46, Michael Meeks  wrote:

>  + also looked at Windows build / CPU
> + total time ~50mins
>   + 5 minutes at the begin – checkout/dep gen.
>   + 8 min in middle & end – just 1 CPU core.
>   + 20mins – with just 1 core.
> + so should run concurrent builds to make better use of 32 threads
> + want to enable it in Jenkins for real builds.
>

​I've pushed a couple of Windows build improvements (e.g. building Python
in parallel) and I intend to push a few more, but mostly I'm focusing on
low hanging fruit e.g. new compiler and linker flags that we can take
advantage of now that we req​uire VS2015
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Minutes of ESC call: 2018-05-30

[Jan Iversen]

Enviado desde mi iPad

> El 30 may 2018, a las 18:38, Jan Holesovsky  escribió:
> 
> * Present:
>+ Thorsten, Kendy, Heiko, Noel, Olivier, Xisco, Bubli, Stephan, Sophie,
>  Michael W., Drew, Eike, Cloph
+ jani (I was the first, when you asked for names).
Rgds
Jan I.
> 
> * Completed Action Items:
> 
> * Pending Action Items:
> 
> * Release Engineering update (Christian)
>+ 6.0.5 – RC1 – this week.
>+ about to tag  
>+ 6.1.0 beta 1 status …
>+ out for a few days now
>+ beta 2 on June 12th – Cloph plans to do the Beta 2
>+ 6.1 late features
>+ calc threading default / fixing (Miklos)
>   + ongoing – more fixes this week.
>+ writer – red-lining re-factoring (Michael S)
>   + ongoing, to be pushed the next week hopefully
>   + switch to switch those 2
>+ KDE5 work (Bubli/Thorsten)
>   + canceled for 6.1, gets merged into master the next days, with the 
> view
> to ship it in 6.2 then
>+ Help format (Stephan)
>   + still trying to figure out how to make extension help work with 
> the
> new format
>+ Get-involved info-bar & Help/About menu (Michael)
>+ Renewed the Windows certificate for another year (watch out QA).
>+ Remotes
>+ iOS remote pending Apple’s approval.
>+ Android viewer
>+ Online
>+ waiting for -6-1 branch.
> 
> * Documentation (Olivier)
>+ New Help
> + Tested build with sberg : OK
> + has a localized build now
> + Discuss: Need a tinderbox to build offline new Help 
>+ “--with-help=html”
> + Tweaks for GDPR in online pages.
>+ Help Pages
> + fixes 
> + Doc bugs triaging.
>+ Guides
> + Sprint Revision week 
>  + 6 of 16 chapters ready for publication
>  + 10 more needed still, but progressing
>  + Missing team members
> 
> * UX Update (Heiko)
>+ Bugzilla (topicUI) statistics
>247(247) (topicUI) bugs open, 315(315) (needsUXEval)
>+ Updates:
>BZ changes   1 week   1 month3 months   12 months  
> added 1(-2)  7(-7) 33(-5) 103(-5) 
> commented 8(-32)   110(-67)   461(-51)   1890(-64)
>   removed 0(0)   0(0)   2(0)   11(0)  
>  resolved 2(1)   5(-1) 31(1)  180(0)  
>+ top 10 contributors:
>  Tietze, Heiko made 46 changes in 1 month, and 813 changes in 1 year
>  Pedro made 35 changes in 1 month, and 44 changes in 1 year
>  Cor Nouws made 14 changes in 1 month, and 155 changes in 1 year
>  Thomas Lendo made 12 changes in 1 month, and 395 changes in 1 year
>  Dieter Praas made 10 changes in 1 month, and 141 changes in 1 year
>  Xisco Faulí made 8 changes in 1 month, and 330 changes in 1 year
>  Foote, V Stuart made 8 changes in 1 month, and 265 changes in 1 year
>  Henschel, Regina made 7 changes in 1 month, and 107 changes in 1 year
>  Kainz, Andreas made 7 changes in 1 month, and 23 changes in 1 year
>  Buovjaga made 7 changes in 1 month, and 191 changes in 1 year
> 
>  + Late feature coming with flat MIME icons
>+ https://bugs.documentfoundation.org/show_bug.cgi?id=117456
>+ https://gerrit.libreoffice.org/#/c/54990/
>+ Andreas K. working on this
>+ documentation team informed
> 
> * Crash Reporting (Caolan)
>+ 6(-11) import failure, 3(+0) export failures
>   + 2 exports – mst layout asserts.
>   + fast-parser fix integrated.
>+ coverity
>+ ?? 6 (+3, -9)
>+ forcepoint round 7.
>+ ??
>+ oss-fuzz ?? (10 outstanding, 9 minor)
> 
> * Crash Reporting (Xisco)
>+ http://crashreport.libreoffice.org/stats/version/5.4.5.1 
>  + 650 (last 7 days) (+35)
>+ http://crashreport.libreoffice.org/stats/version/5.4.6.2 
>  + 724 (last 7 days) (+63)
>+ http://crashreport.libreoffice.org/stats/version/5.4.7.2
>  + 340 (last 7 days) (+116)
>+ http://crashreport.libreoffice.org/stats/version/6.0.3.2
>  + 1167 (last 7 days) (-165)
>+ http://crashreport.libreoffice.org/stats/version/6.0.4.2
>  + 1228 (last 7 days) (+216)
> 
> * Budget ranking (Thorsten)
>   + on ESC share - “Budget2018” - add your ranking.
> 
> * GSoC schedule (Heiko)
>   + Coding: May 14 - August 6
>   + please tell students to send a weekly status upate.
>   + Evaluation 1: June 11 - 15
>   + Evaluation 2: July 9 - 13
>   + Students Submit Code and Final Evaluations: August 6 - 14
>   + Mentors Submit Final Evaluations: August 14 - 21
>   + Results Announced: August 22
>   + https://wiki.documentfoundation.org/Development/GSoC/2018
> 
> * Hackfests & Events
>   + a hole here – potential one in Switzerland later in the year.
>   + call for papers for the LibreOffice Conference still ongoing! (Sophie)
>  + deadline: mid-July
> 
> * mentoring/ea

Re: minutes of ESC call ... ( 29-03-2018 )

[Heiko Tietze]

On 03.04.2018 22:39, Khaled Hosny wrote:
> On Tue, Apr 03, 2018 at 05:24:16PM +0200, Xisco Fauli wrote:
>> Updated Linux and got Colibre (Xisco) + may happen on not KDE3/4,
>> Trinity, Unity, GNOME etc. (Heiko) ]
> 
> I’m on Gnome and I get new icon theme (I assume this is Colibre).
> 

Join the discussion

https://bugs.documentfoundation.org/show_bug.cgi?id=116695
https://gerrit.libreoffice.org/#/c/52117/
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: minutes of ESC call ... ( 29-03-2018 )

[Khaled Hosny]

On Tue, Apr 03, 2018 at 05:24:16PM +0200, Xisco Fauli wrote:
>  Updated Linux and got Colibre (Xisco)
> + may happen on not KDE3/4, Trinity, Unity, GNOME etc. (Heiko) ]

I’m on Gnome and I get new icon theme (I assume this is Colibre).

Regards,
Khaled
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: minutes of ESC call ...

[Thorsten Behrens]

Michael Meeks wrote:
> + go over the past budget ideas & cleanup as a base (Thorsten)
> 
First round done - see:

> * Budgeting (Thorsten)
> + collecting other wish-lists – cross-check with GSoC ideas
> + current ideas 
> list:https://wiki.documentfoundation.org/Development/Budget2018
> 
If people could please double-check that list & remove things that are
done or obsolete - and then we probably want to clone useful ideas to
the gsoc page (and vice versa).

Cheers,

-- Thorsten


signature.asc
Description: Digital signature
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Minutes of ESC call 2018-02-01

[Noel Grandin]

On 1 February 2018 at 18:54, Jan Holesovsky  wrote:

>
>
> * Budgeting (Thorsten)
> + collecting wish-lists:
> + get some fast new Macs and host at Manitu
> + gerrit updates
> + other ideas for development topics ?
>
>
SSDs for existing macs.

SSD for gerrit (I often find it slow, but maybe that's just my internet
connection).

Maybe Cloudflare or similar for our Manitu network would help people like
me at the other end of international links?
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: minutes of ESC call ...

[Sophia Schröder]

* Hackfests & Events (Thorsten)
 + FOSDEM hack-fest / meetings
 + confirmed for following Monday/Tuesday at ICAB
 + dates confirmed (Monday + Tuesday), book your travel!
 + Bedford – overbooked right now; didn’t get a group rate (Heiko)
 + hurry to book.
 + La Grande Cloche over the street.
 + Hamburg – 1st new-style hackfest
 + deferred to next year ...
 + https://wiki.documentfoundation.org/Hackfests/HackfestTNG
 + should meet with locals
 + fallback plan for March in either Italy or Germany
 +*still looking for people who want help learning how to fix their 
problems interactively at a hackfest.***
Here, here!!! I'd love to learn how to fix spelling, grammar and other 
mistakes

in the sources of our UI, help system and so by myself instead just to tell:
"Here is one!!1!11!" and waiting for others (e.g. Gabor, Olivier, 
Sophie)  to correct them (or not).
Were good to learn that vis a vis with someone for sending my first 
patches in Gerrit.


* mentoring/easyhack update
   committer...   1 week 1 month 3 months12 months
   open  67(-14)117(-14)119(-13) 123(-13)
reviews 599(-4)2202(208)   4894(-30)   18690(136)
 merged 428(86)1551(229)   3557(192)   11871(204)
  abandoned  28(-14)135(14) 267(17)  744(18)
own commits 339(-8)1545(76)4246(-9)13944(181)
 review commits  56(-15)343(5)  866(-9) 3337(5)
 contributor...   1 week 1 month 3 months12 months
   open  17(-6)  38(3)   39(1)43(1)
reviews 845(-80)   3324(190)   7735(111)   24245(279)
 merged  13(-15) 85(-9) 234(-9) 1183(-1)
  abandoned   2(-6)  23(-1)  57(-4)  346(-1)
own commits  13(-15) 86(-9) 240(-10) 866(-11)
 review commits   0(0)0(0)0(0) 0(0)
 + easyHack statistics:
needsDevEval 37(37)   needsUXEval 1(1)   cleanup_comments 206(206)
total 255(255)   assigned 24(24)   open 192(192)
 + top 5 contributors:
   Gelmini, Andrea made 24 patches in 1 month, and 211 patches in 1 year
   Goncharuk, Lera made 8 patches in 1 month, and 13 patches in 1 year
   Donkers, Winfried made 8 patches in 1 month, and 29 patches in 1 year
   Gabriel Chiquini made 4 patches in 1 month, and 6 patches in 1 year
   Latini, Marina made 3 patches in 1 month, and 4 patches in 1 year
 + top 5 reviewers:
   Pootle bot made 237 review comments in 1 month, and 741 in 1 year
   Holešovský, Jan made 203 review comments in 1 month, and 1143 in 1 
year
   Behrens, Thorsten made 195 review comments in 1 month, and 1068 in 1 
year
   Stahl, Michael made 195 review comments in 1 month, and 1987 in 1 
year
   Rathke, Eike made 152 review comments in 1 month, and 1142 in 1 year
 + big CONGRATULATIONS to contributors who have at least 1 merged patch, 
since last report:

* XHTML export filter (Miklos)
 + remember recent commits for XHTML / XSLT.
 + added a new flag to HTML export to produce XHTML
 + far from perfect but a good start.
 + profiling XHTML export – a large cost is compiling XSLT thing.
 + 2x XHTML exports in writer.
 + XSLT is the default still, but now have the C++ one too.
 + in case no-one shouts: prefer to move to C++ not XSLT
 + no time for it just now to do it completely.
 + thoughts ?
 + no fan of XSLT (Thorsten)
 + fixing bits here & there had to re-write.
 + one good bit – exercises the flat-odf filter
 + Regina working on fixing that.
 + perhaps keep it around and deprecate it.
 + generally the concept is powerful if you love XSLT (Thorsten)
 + patch to change type of pictures (Kendy)
 + useful for flat-odt (Thorsten)

* Commit Access

* Developer Certification (Stephan/Bjoern/Kendy/Thorsten)
 + sleep for 16 weeks.

* Jenkins / CI update (Christian)
 from:Thu Dec 14 16:17:23 2017
 master linux rel  jobs: 204 ok: 201 ko:   3 fail ratio:  1.47 % break:   2 
broken duration: 0.17%
 master linux dbg  jobs: 133 ok: 130 ko:   1 fail ratio:  0.75 % break:   1 
broken duration: 0.74%
 master mac reljobs: 141 ok: 140 ko:   1 fail ratio:  0.71 % break:   1 
broken duration: 1.15%
 master mac dbgjobs: 137 ok: 135 ko:   2 fail ratio:  1.46 % break:   2 
broken duration: 2.71%
 master win reljobs:  94 ok:  85 ko:   9 fail ratio:  9.57 % break:   9 
broken duration:11.47%
 master win dbgjobs: 114 ok: 101 ko:  13 fail ratio: 11.40 % break:  12 
broken duration: 9.92%
 master win64 dbg  jobs: 106 ok:  93 ko:  13 fail ratio: 12.26 % break:  12 
broken duration: 8.68%
 

Re: minutes of ESC call ...

[Tomaž Vajngerl]

Hi,

On Fri, Dec 22, 2017 at 12:52 AM, Michael Meeks
 wrote:
>
> * Blurry icons (Heiko)
> + a PNG issue for hidpi screens.
> + why not use SVG icons instead ?
> + quikee wrote some code to render SVG icons (Kendy)
>+ need to look into what the state is

There are 2 issues currently:
- SVG import doesn't correctly interpret what should happen when
"height" and "width" aren't set but just "viewBox", so many SVG icons
aren't rendered correctly. I have a fix for that, but need to write a
test too.

- When using GTK3 we use the cairo HiDPI scaling instead of handling
that ourselves. The issue is that rendering bitmaps need to support
that too, which we don't. For example if we have an icon 24x24 px
which is rendered to 48x48 actual px from SVG (2x HiDPI scaling) must
still pretend to be 24x24 px and drawn to a 24x24 px area on a cairo
surface (cairo surface uses non-scaled size and just internally scales
them to 2x the size) . So our "Image" class must know something about
scaling to draw the icons correctly in this case. I have made a crude
POC and it worked, but not yet ready for production.

>+ adds some startup-time potentially.
>+ need to measure startup impact.

SVG icons are on demand rendered and then cached to PNG in profile
"cache" folder. So the rendering impact would only be for the first
time an icon is used, after that the impact is the same as using a PNG
icon - until the cache is cleared  (which is currently never - users
must do it themselves).

> + SVG renderer we have is not the fastest in the world (Thorsten)
>+ with some caching – in a good shape.
> + thought it was solved ? Just switching.
> => ask quikee what he recommends.

When those 2 bugs are solved, all we need to do is package the SVG
icons. At least breeze_svg icons work as they are very simple. Others
(elementary for example) could render wrongly, I didn't try it yet.
OTOH some Tango SVG icons did crash the renderer so currently we
always prefer PNG icon over SVG if both are present (like in Tango)
and the icon theme must be a pure SVG themes (with no PNG present in
the zip file) if SVG would be used.

Regards, Tomaž
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: minutes of ESC call ...

[Tommy]

Tommy wrote:

Michael Meeks wrote:

.
    + 5.4.4 RC2 status
.

no bugfix list has been published yet about RC1 and RC2 in the wiki

https://wiki.documentfoundation.org/ReleasePlan/5.4#5.4.4_release




nevermoind. it's fixed now

---
Questa email è stata esaminata alla ricerca di virus da AVG.
http://www.avg.com


___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: minutes of ESC call ...

[Tommy]

Michael Meeks wrote:

.
+ 5.4.4 RC2 status
.

no bugfix list has been published yet about RC1 and RC2 in the wiki

https://wiki.documentfoundation.org/ReleasePlan/5.4#5.4.4_release

---
Questa email è stata esaminata alla ricerca di virus da AVG.
http://www.avg.com


___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: minutes of ESC call ...

[Miklos Vajna]

Hi Stephan,

On Wed, Nov 08, 2017 at 09:44:02AM +0100, Stephan Bergmann 
 wrote:
> And, just to clarify, for me that means that enforcement on new files cannot
> be opt-in based on whatever personal concerns, as might be read out of the
> commit message of 
> 
> "test: clang-format recently added xsheet tests":  "Jens says he was unhappy
> with the 80 cols limit, so clang-format was explicitly avoided for these new
> files [...]"

Makes sense -- the Code-Review label discussion in the other thread
sounds like we'll have the enforcement at a gerrit level (as well) soon,
which should address the case when enforcement is avoided locally
(either implicitly or explicitly).

Regards,

Miklos


signature.asc
Description: Digital signature
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: minutes of ESC call ...

[Stephan Bergmann]

On 11/03/2017 10:05 AM, Stephan Bergmann wrote:

On 11/02/2017 06:10 PM, Michael Meeks wrote:

* clang-format-ness (Miklos)

[...]

 + propose merge step#1 without clang-format enforced (Michael)
    + don’t like the auto-re-format of others’ commits (Stephan)
   + if want to have enforced – make sure all commits is 
formatted right

 or we get these issues.


To maybe clarify that a bit:  I see no value at all in enforcing any 
formatting as an end in itself.  I only see it as a means to drop the 
future amount of reformatting commits to zero.  (What I mean with 
"reformatting commits" is both commits that do no changes other than 
reformatting source code, as well as commits that mix---related, or even 
unrelated---reformatting of source code with some "real" changes. Either 
form creates "noise" that makes it harder to inspect individual git 
commits and the git history.)


The only way I see how we can reach that goal of zero future 
reformatting commits is to have the invariant that all commits to the 
central git repo are enforce-formatted (after one round of "big noise" 
reformatting any existing source code, if we ever get there).


And, just to clarify, for me that means that enforcement on new files 
cannot be opt-in based on whatever personal concerns, as might be read 
out of the commit message of 
 
"test: clang-format recently added xsheet tests":  "Jens says he was 
unhappy with the 80 cols limit, so clang-format was explicitly avoided 
for these new files [...]"

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: minutes of ESC call ...

[Kaganski Mike]

On 11/2/2017 8:10 PM, Michael Meeks wrote:
> * Completed Action Items:
>  + ship the horror win / VC runtime DLLs with the installer (Cloph)
>  [ patch appears to work, but we already have them in the installer
>if you do an admin-install they are already installed.
>we ship them twice – once as LibreOffice, but once as a run-time 
> module
>not entirely elegant.
>for 5.4 – merge it as-is, for 6.0 do something clever.
> http://dev-builds.libreoffice.org/daily/libreoffice-5-4/Win-x86@62-TDF/tdf_108580/
>  ]

1. For 6.0, we would not need to ship the merge module - because that 
module is only working for WinXP. So that leaves us with just one copy.

2. Still, having app-local DLLs is worse than system-updateable (at 
least security-wise: if we bundle app-local DLLs, then we would have to 
put their advisories to our site? so that users using not-up-to-date LO 
versions could know that they might be vulnerable, despite having 
updated their systems). So, we could try to include MSUs from KB2999226 
[1]. There are 3 different packages for each bitness that cover all 
supported platforms requiring the update (Win7, Win8, Win8.1):
- for x86:
   Windows6.1-KB2999226-x86.msu
   Windows8-RT-KB2999226-x86.msu
   Windows8.1-KB2999226-x86.msu
- for x64:
   Windows6.1-KB2999226-x64.msu
   Windows8-RT-KB2999226-x86.msu
   Windows8.1-KB2999226-x64.msu

The size of all three x86 packages is 1.77 MB total; three x64 packages 
are 3.24 MB total.

The MSUs are installable using Windows Update Standalone Installer [2] 
(system component in all those Windows versions). Custom actions would 
need to be created, with relevant conditions (VersionNT; [3]).

The drawbacks (besides extra size):
1. We need to also check for pre-conditions: if the KB2999226 is already 
installed; if required pre-requisite KBs are present (see [1]; 
prerequisites exist for Win7 and Win8.1 - curiously no preconditions for 
Win8). For Win7, the prerequisite is SP1, so may just state this version 
as system requirement? For Win8.1, the prerequisite is [4], which is 
several hundred MB...
2. We somehow need to get the packages to dev environment when building 
the installer - should we put the blobs to our server to fetch as 
external package on build? (I don't know if there's a static URL for 
those files on MS site.)

[1] https://support.microsoft.com/en-us/help/2999226
[2] https://support.microsoft.com/en-us/help/934307
[3] https://msdn.microsoft.com/en-us/library/aa370556
[4] https://support.microsoft.com/en-us/help/2919355

-- 
Best regards,
Mike Kaganski
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: minutes of ESC call ...

[Miklos Vajna]

Hi,

On Fri, Nov 03, 2017 at 10:05:05AM +0100, Stephan Bergmann 
 wrote:
> The only way I see how we can reach that goal of zero future reformatting
> commits is to have the invariant that all commits to the central git repo
> are enforce-formatted (after one round of "big noise" reformatting any
> existing source code, if we ever get there). Therefore, I am not interested
> in experiments that cover some subset of the git repo's files but are done
> in a way that they don't guarantee that invariant over that subset.  My fear
> is that such experiments will increase the level of noise in the repo,
> instead of helping to keep it flat at its historical level.

So in case some mechanism in gerrit and (for those who decide to push
directly and have clang-format installed locally) the pre-commit git
hook is in place, that addresses this concern, I hope.

Seeing the recent thread "Gerrit Code-Review +1 / -1" (from Kendy), I
hope not only the git hook part, but also the gerrit part will be a
reality in the near future.

Regards,

Miklos


signature.asc
Description: Digital signature
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: minutes of ESC call ...

[Stephan Bergmann]

On 11/02/2017 06:10 PM, Michael Meeks wrote:

* clang-format-ness (Miklos)

[...]

 + propose merge step#1 without clang-format enforced (Michael)
+ don’t like the auto-re-format of others’ commits (Stephan)
   + if want to have enforced – make sure all commits is formatted right
 or we get these issues.


To maybe clarify that a bit:  I see no value at all in enforcing any 
formatting as an end in itself.  I only see it as a means to drop the 
future amount of reformatting commits to zero.  (What I mean with 
"reformatting commits" is both commits that do no changes other than 
reformatting source code, as well as commits that mix---related, or even 
unrelated---reformatting of source code with some "real" changes. 
Either form creates "noise" that makes it harder to inspect individual 
git commits and the git history.)


The only way I see how we can reach that goal of zero future 
reformatting commits is to have the invariant that all commits to the 
central git repo are enforce-formatted (after one round of "big noise" 
reformatting any existing source code, if we ever get there). 
Therefore, I am not interested in experiments that cover some subset of 
the git repo's files but are done in a way that they don't guarantee 
that invariant over that subset.  My fear is that such experiments will 
increase the level of noise in the repo, instead of helping to keep it 
flat at its historical level.

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Minutes of ESC call 2017-10-26

[Thorsten Behrens]

Miklos Vajna wrote:
> * clang-format-ness (Miklos)
> + Came up with a prototype at https://gerrit.libreoffice.org/#/c/43736/ 
>  + Tamas Z: autofix up style → added a config option
>  + Thorsten: server-side idea
>+ not clear if it’s nice-to-have or a blocker if not addressed (Miklos)
>  + Stephan: maintenance concern with given style config
>+ not a blocker, but having one more week to research this would be 
> nice (Stephan)
> 
> => discuss this once again next week
> 
Thanks for postponing a bit - my concerns are not a blocker of course,
just a strong desire to keep whatever a dev needs to hack (and commit!)
on LibreOffice code as lightweight as possible.

Having something on gerrit and/or jenkins pushes a potentially complex
& growing moving piece to a centrally-administered place...

Cheers,

-- Thorsten


signature.asc
Description: Digital signature
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Minutes of ESC call 2017-10-26

[Noel Grandin]

On 26 October 2017 at 16:59, Miklos Vajna  wrote:

> + Most Pressing Bugs: http://tdf.io/mostressingbugs
> + New:
>  + Crash in: ScPreview::MouseMove(MouseEvent const &)
>+ https://bugs.documentfoundation.org/show_
> bug.cgi?id=113422
>+ bisected to Noel (?)
>


Fix for this has just been pushed to gerrit.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Minutes of ESC call 2017-09-21

[Khaled Hosny]

On Mon, Sep 25, 2017 at 12:06:42PM +0200, Xisco Fauli wrote:
> Hello Khaled,
> 
> > * Reverting ‘tdf#103831, tdf#100986: Force using GDI when needed’ for 
> > 5.3.7? (Xisco)
> > + 
> > https://cgit.freedesktop.org/libreoffice/core/commit/?id=a51b7a1c3a7e7cf7b0c733e1dec40288278c1884
> > + Fixes:
> > + Horizontal Text: 
> > https://bugs.documentfoundation.org/show_bug.cgi?id=103831
> > + Rotated Text: 
> > https://bugs.documentfoundation.org/show_bug.cgi?id=100986
> > + Introduced:
> > + META: https://bugs.documentfoundation.org/show_bug.cgi?id=112486 
> > + Font rendering issue.
> >  + Khaled’s commit – can you talk to him first? (Kendy)
> > AI:  + will talk to Khaled (Xisco)
> >
> Any objection/comment/opinion about getting this commit reverted in 5.3.7 ?

Hmm, I don’t think you need to revert the whole change. Looking into
this again, I think there are two unrelated changes in this commit;
forcing GDI for non-horizontal text which fixed the two bugs, and
optionally not using GDI when not using OpenGL (previously we always
used GDI when OpenGL was used). I think it was wishful thinking of my
part to think the non-GDI code path is usable.

In short, I guess you just need to change the !bUseOpenGL branch back to:

DrawTextLayout(rLayout, hDC, false);

This should fix the newly introduced issues. I can’t test this myself
right now, though, and might not be able to do so for few more weeks.
It might also cause a regression for some Graphite fonts, but I
don’t remember the details, but it shouldn’t be hard to have a
CommonSalLayout::isGraphite() or so to signal such fonts and not use
GDI for them.

Regards,
Khaled
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Minutes of ESC call 2017-09-21

[Xisco Fauli]

Hello Khaled,

> * Reverting ‘tdf#103831, tdf#100986: Force using GDI when needed’ for 5.3.7? 
> (Xisco)
> + 
> https://cgit.freedesktop.org/libreoffice/core/commit/?id=a51b7a1c3a7e7cf7b0c733e1dec40288278c1884
> + Fixes:
>   + Horizontal Text: 
> https://bugs.documentfoundation.org/show_bug.cgi?id=103831
>   + Rotated Text: 
> https://bugs.documentfoundation.org/show_bug.cgi?id=100986
> + Introduced:
>   + META: https://bugs.documentfoundation.org/show_bug.cgi?id=112486 
>   + Font rendering issue.
>  + Khaled’s commit – can you talk to him first? (Kendy)
> AI:  + will talk to Khaled (Xisco)
>
Any objection/comment/opinion about getting this commit reverted in 5.3.7 ?

Regards

-- 
Xisco Faulí
Libreoffice QA Team
IRC: x1sc0


___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Minutes of ESC call 2017-09-21

[Noel Grandin]

On 21 September 2017 at 21:01, Jan Holesovsky  wrote:

> + wrt. Download – should we still default to 32bit? (Stephan)
> + website defaults to that (Cloph)
> + the browsers don’t indicate 64bit on Windows (Cloph)
>

https://stackoverflow.com/questions/1741933/detect-64-bit-or-32-bit-windows-from-user-agent-or-javascript
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: minutes of ESC call ...

[Caolán McNamara]

On Thu, 2017-08-31 at 15:49 +0100, Michael Meeks wrote:
> Looked for related bugs in Bugzilla (Xisco)
>+ didn’t look in too much detail
> + http://nabble.documentfoundation.org/Minutes-of-ESC-call-20
> 17-08-17-tt4220768.html#a4221038
> AI:+ dialog / cropping → perhaps have a look / Caolan ?

https://gerrit.libreoffice.org/#/c/41933/ is my suggestion, round to
int instead of truncate
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: minutes of ESC call ...

[Michael Meeks]

Hi there,

On 31/08/17 16:35, khagaroth wrote:
> On Thu, Aug 31, 2017 at 4:49 PM, Michael Meeks
> mailto:michael.me...@collabora.com>> wrote:
> 
>+ calc/PDF – wrt. line-breaking: most concern
>   + Khaled ? driven away by annoying reporter ?
>   *+ calc issue appears to affect only him → ignore it?
> (Xisco)*
>  + declared strategy to annoy people to fix his bugs
> (Thorsten)
> + should we mute / give him a stern talk ?
> 
> 
> Care to elaborate how it only affects him? I have hundreds of existing
> calc documents with multiline text that are now broken (ie they
> display/print/export badly)

Did you file a bug or two ? I imagine this is based on Xisco's
extensive bug reading.

Of course, it is a shame that one person's bad attitude causes people
to get upset; if it is not something affecting just them - then its
worthy of wider examination I guess.

The more help with this class of bugs - poking the code, investigating
causes, and/or when the regression got introduced, reading the patches &
coming up with a solution the better - much appreciated.

ATB,

Michael.

-- 
michael.me...@collabora.com <><, Pseudo Engineer, itinerant idiot
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: minutes of ESC call ...

[khagaroth]

On Thu, Aug 31, 2017 at 4:49 PM, Michael Meeks 
wrote:

>+ calc/PDF – wrt. line-breaking: most concern
>   + Khaled ? driven away by annoying reporter ?
>   *+ calc issue appears to affect only him → ignore it?
> (Xisco)*
>  + declared strategy to annoy people to fix his bugs
> (Thorsten)
> + should we mute / give him a stern talk ?
>

Care to elaborate how it only affects him? I have hundreds of existing calc
documents with multiline text that are now broken (ie they
display/print/export badly) and I'm definitely not going to go trough all
of them to fix it manually. And no, they don't use some exotic fonts, 99%
of them are using Arial or Times.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Minutes of ESC call 2017-08-17

[khagaroth]

So what's the plan for handling the line spacing changes outfall? After
this change LO is currently unusable as it completely breaks existing
documents and the bugs don't see much activity.

On Mon, Aug 21, 2017 at 8:05 PM, Xisco Fauli 
wrote:

> Hello,
> > + build a write-up of the differences cross-platform (Xisco)
> >   [ almost done, will send to the ML ]
> >
> Basically the line spacing differences across platforms has been reduced
> after this commit[1] ( visual example of an issue fixed by the mentioned
> commit: Windows [2] and Linux [3] ) although there are still some bugs
> showing differences between Linux and Windows [4][5]
> Besides, it seems some documents look different before and after the
> commit now.
> These are the problems I could find in Bugzilla related to the commit:
>
> 1. Some fonts with bad metrics ( [6],[7] ) were displayed better before,
> however the problem needs to be fixed in the fonts, not in LibreOffice,
> thus, NOTOURBUG.
> Note: Khaled also fixed it for OpenSymbol fonts [9].
>
> 2. UI: Some dialogs labels are slightly cropped and vertically cramped
> [9]. Differences look bigger on Linux/Mac than on Windows. This bug [10]
> seems similar.
>
> 3. Web view: Line spacing is smaller than before [11]. This really looks
> like a bug to me.
>
> 4. Calc/PDF: line spacing looks smaller when using line breaks [12].
>
> As a solution, this bug [13] has been suggested.
>
> Regards
>
> [1]
> https://cgit.freedesktop.org/libreoffice/core/commit/?id=
> 34d7602954d4483b3bc9db700e7df2c15348947a
> [2] https://bug-attachments.documentfoundation.org/
> attachment.cgi?id=128520
> [3] https://bug-attachments.documentfoundation.org/
> attachment.cgi?id=128521
> [4] https://bugs.documentfoundation.org/show_bug.cgi?id=92502
> [5] https://bugs.documentfoundation.org/show_bug.cgi?id=104932
> [6] https://bugs.documentfoundation.org/show_bug.cgi?id=107605
> [7] https://bugs.documentfoundation.org/show_bug.cgi?id=107888
> [8] https://bugs.documentfoundation.org/show_bug.cgi?id=106994#c7
> [9] https://bugs.documentfoundation.org/show_bug.cgi?id=107249
> [10] https://bugs.documentfoundation.org/show_bug.cgi?id=105860
> [11] https://bugs.documentfoundation.org/show_bug.cgi?id=108710
> [12] https://bugs.documentfoundation.org/show_bug.cgi?id=106111
> [13] https://bugs.documentfoundation.org/show_bug.cgi?id=108891
>
> --
> Xisco Faulí
> Libreoffice QA Team
> IRC: x1sc0
>
>
> ___
> LibreOffice mailing list
> LibreOffice@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/libreoffice
>
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Minutes of ESC call 2017-08-24

[Pranav Kant]

Hi,

On 24/08/17 20:23, Miklos Vajna wrote:

* GSoC update (Thorsten / Markus / JanI)
 + timeline:
 + August 21 - 29: pens down, wrap up – this is now!
 + August 29 - September 5: final evaluations of students
 + September 6: passing projects announced
 + one open slot for mentor summit – Oct. 15-16 (right after LibOCon)
 + tell Thorsten if you are a mentor this year & want to go!


I discussed with Thorsten that I am interested to take this empty slot, and now going ahead with the 
registration etc. for the summit.


Thanks !

--
Regards,
Pranav
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Minutes of ESC call 2017-08-24

[Jean-Baptiste Faure]

Hi,

Le 24/08/2017 à 16:53, Miklos Vajna a écrit :

[...]
* Release Engineering update (Christian)
 + 5.3.6 RC1 is on the mirrors, to be announced early next week


Some time ago, new RC builds were systematically announced on several ML 
(dev, QA, projects). Now, several RC were not announced (notably 5.3.5), 
and probably not tested by advanced users and QA members before the release.


Is it a change in the release engineering process, or just an oversight?

Best regards.
JBF

--
Seuls des formats ouverts peuvent assurer la pérennité de vos documents.
Disclaimer: my Internet Provider being located in France, each of our
exchanges over Internet will be scanned by French spying services.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Minutes of ESC call 2017-08-17

[Xisco Fauli]

Hello,
> + build a write-up of the differences cross-platform (Xisco)
>   [ almost done, will send to the ML ]
>
Basically the line spacing differences across platforms has been reduced
after this commit[1] ( visual example of an issue fixed by the mentioned
commit: Windows [2] and Linux [3] ) although there are still some bugs
showing differences between Linux and Windows [4][5]
Besides, it seems some documents look different before and after the
commit now.
These are the problems I could find in Bugzilla related to the commit:

1. Some fonts with bad metrics ( [6],[7] ) were displayed better before,
however the problem needs to be fixed in the fonts, not in LibreOffice,
thus, NOTOURBUG.
Note: Khaled also fixed it for OpenSymbol fonts [9].

2. UI: Some dialogs labels are slightly cropped and vertically cramped
[9]. Differences look bigger on Linux/Mac than on Windows. This bug [10]
seems similar.

3. Web view: Line spacing is smaller than before [11]. This really looks
like a bug to me.

4. Calc/PDF: line spacing looks smaller when using line breaks [12].

As a solution, this bug [13] has been suggested.

Regards

[1]
https://cgit.freedesktop.org/libreoffice/core/commit/?id=34d7602954d4483b3bc9db700e7df2c15348947a
[2] https://bug-attachments.documentfoundation.org/attachment.cgi?id=128520
[3] https://bug-attachments.documentfoundation.org/attachment.cgi?id=128521
[4] https://bugs.documentfoundation.org/show_bug.cgi?id=92502
[5] https://bugs.documentfoundation.org/show_bug.cgi?id=104932
[6] https://bugs.documentfoundation.org/show_bug.cgi?id=107605
[7] https://bugs.documentfoundation.org/show_bug.cgi?id=107888
[8] https://bugs.documentfoundation.org/show_bug.cgi?id=106994#c7
[9] https://bugs.documentfoundation.org/show_bug.cgi?id=107249
[10] https://bugs.documentfoundation.org/show_bug.cgi?id=105860
[11] https://bugs.documentfoundation.org/show_bug.cgi?id=108710
[12] https://bugs.documentfoundation.org/show_bug.cgi?id=106111
[13] https://bugs.documentfoundation.org/show_bug.cgi?id=108891

-- 
Xisco Faulí
Libreoffice QA Team
IRC: x1sc0


___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Minutes of ESC call 2017-08-03

[Caolán McNamara]

On Sat, 2017-08-05 at 22:15 +0200, Jean-Baptiste Faure wrote:
> Hi,
> 
> Le 03/08/2017 à 21:23, Caolán McNamara a écrit :
> > On Thu, 2017-08-03 at 16:47 +0200, Miklos Vajna wrote:
> > > * l10n (Sophie/Christian)
> > >  + duplicate strings in templates w/ gettext on master:
> > >mainly in sd/messages.pot – printindialog.ui from various
> > >subdirs
> > >+ preferred would be: have them in separate files
> > 
> > I guess this is sd/uiconfig/sdraw/ui/printeroptions.ui and
> > sd/uiconfig/simpress/ui/printeroptions.ui. Is the problem just with
> > the output of "make translations" i.e. the generated
> > workdir/sd/messages.pot if so, then yeah a simple rename will do
> > the
> > tricky, i.e. https://gerrit.libreoffice.org/#/c/40747/ and that
> > seems
> > to be the only case (according to msgcat workdir/*/messages.pot)
> 
> There is this bug report, still unconfirmed:
> https://bugs.documentfoundation.org/show_bug.cgi?id=107611
> duplicate message definitions in some .pot files

That one however is (up to) 5-4 so not exactly the reported problem
here. Though I think a side effect (now that the above change is done)
of the changes for gettext is that tdf#107611 should be gone in master
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Minutes of ESC call 2017-08-03

[Jean-Baptiste Faure]

Hi,

Le 03/08/2017 à 21:23, Caolán McNamara a écrit :

On Thu, 2017-08-03 at 16:47 +0200, Miklos Vajna wrote:

* l10n (Sophie/Christian)
 + duplicate strings in templates w/ gettext on master:
   mainly in sd/messages.pot – printindialog.ui from various
   subdirs
   + preferred would be: have them in separate files


I guess this is sd/uiconfig/sdraw/ui/printeroptions.ui and
sd/uiconfig/simpress/ui/printeroptions.ui. Is the problem just with
the output of "make translations" i.e. the generated
workdir/sd/messages.pot if so, then yeah a simple rename will do the
tricky, i.e. https://gerrit.libreoffice.org/#/c/40747/ and that seems
to be the only case (according to msgcat workdir/*/messages.pot)


There is this bug report, still unconfirmed:
https://bugs.documentfoundation.org/show_bug.cgi?id=107611
duplicate message definitions in some .pot files

Best regards.
JBF

--
Seuls des formats ouverts peuvent assurer la pérennité de vos documents.
Disclaimer: my Internet Provider being located in France, each of our
exchanges over Internet will be scanned by French spying services.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Minutes of ESC call 2017-08-03

[Caolán McNamara]

On Thu, 2017-08-03 at 16:47 +0200, Miklos Vajna wrote:
> * l10n (Sophie/Christian)
> + duplicate strings in templates w/ gettext on master:
>   mainly in sd/messages.pot – printindialog.ui from various 
>   subdirs
>   + preferred would be: have them in separate files

I guess this is sd/uiconfig/sdraw/ui/printeroptions.ui and
sd/uiconfig/simpress/ui/printeroptions.ui. Is the problem just with
the output of "make translations" i.e. the generated
workdir/sd/messages.pot if so, then yeah a simple rename will do the
tricky, i.e. https://gerrit.libreoffice.org/#/c/40747/ and that seems
to be the only case (according to msgcat workdir/*/messages.pot)
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: minutes of ESC call ...

[Terrence Enger]

On Sun, 2017-07-16 at 02:29 +0200, Markus Mohrhard wrote:
> On Fri, Jul
14, 2017 at 11:34 AM, Michael Meeks  ora.com
> > wrote:
> > 
> > 
> > * SSRLabs Interns (Michael)
> > + eight new hacking interns around: performance & quality
> > + starting on their first easy-hacks.
> > + Any ideas on quality ? (Xisco)
> 
> + can write UI test; can take a couple.
> > 
> 
> So there is also one additional idea around that. I already started
> adding
> some code that generates a log file with all the user interaction in
> the
> hope of automatically transforming that data to UI tests (or
> automatic
> replication of bug reports).

It would be particularly good if this logging was sufficiently
performant that a dedicated tester could have it on routinely.  This
would help in the situation when I am surprised without knowing
exactly what I did.

For example, right now I am unable to reproduce a rendering problem in
Writer that I stumbled over while I was doing real work.  Perhaps it
depends on just what edits I made, how I moved the cursor around, what
I undo'd (Let us hope that never becomes a word. ), or even
the content of the document.  As it is now, I have just about given
up.

Terry.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: minutes of ESC call ...

[Heiko Tietze]

On 16.07.2017 02:29, Markus Mohrhard wrote:
>> * SSRLabs Interns (Michael)
> So there is also one additional idea around that. I already started
> adding some code that generates a log file with all the user
> interaction in the hope of automatically transforming that data to UI
> tests (or automatic replication of bug reports).

Can we abuse this data for user metrics? Would be another most-wanted task, 
whether or not based on these log files.



signature.asc
Description: OpenPGP digital signature
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: minutes of ESC call ...

[Markus Mohrhard]

On Fri, Jul 14, 2017 at 11:34 AM, Michael Meeks  wrote:

>
>
> * SSRLabs Interns (Michael)
> + eight new hacking interns around: performance & quality
> + starting on their first easy-hacks.
> + Any ideas on quality ? (Xisco)

+ can write UI test; can take a couple.
>

So there is also one additional idea around that. I already started adding
some code that generates a log file with all the user interaction in the
hope of automatically transforming that data to UI tests (or automatic
replication of bug reports). So if there is a student interested in that he
could work on making sure that all the relevant information is in the log
file, writing a DSL (domain specific language) that represents the
information and a script to automatically convert the generated log file to
something based on the DSL.

This can be combined with the task of writing UI tests and extending the UI
testing to some more complex cases. The huge advantage is that this is a
task that is quite self contained and the code is well maintained. Long
term having the ability to log what a user does in the UI and replay it on
a developer machine would provide some huge benefits for us.


+ Extending performance test-suite (Markus?)
>

So we have at least two features that I would like to see but both are more
web development related. The current perf.libreoffice.org already has the
ability to store a comment for a specific data point but this currently
requires manual execution of a shell script on the server. We should add a
front-end for this feature making it easy to annotate data points with
commits that caused performance changes.

The second feature that I think would be quite useful is to have the
ability to get kcachegrind results for a specific test case and build ID.
Currently there is no way to get useful info from the scripts and it is
quite painful to debug performance problems. the VM is mostly idle during
the European night and could produce the required data. This might also
make it easier for QA and related fields to get good (symbols build,
correct callgrind config) callgrind output. Obviously this requires some
additional concept work.

All in all we can easily keep one student busy with some work here. The
work would be mostly python, scripting, html, js work. The advantage is
that it is a fairly contained project and a student will not need that much
introduction time.

+ XML filter pieces (Michael)
> + continue & expand Azorpid’s work.
> + other misc. threading / perf. Ideas (Michael)
> + UX pieces (Heiko)
> + problem is: need a coding mentor here.
> + missing table styles, area style types etc.
> + page background etc.
> + build performance on windows ? (Thorsten)
>
>
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: minutes of ESC call ...

[Adolfo Jayme Barrientos]

2017-06-29 15:05 GMT+00:00 Stephan Bergmann :
> * Release Engineering update (Christian)
> + 5.4.0 RC1
>   + Jay: XP support missing due to harfbuzz? (compiles and runs, but
> further tests outstanding)
>   + an independant review is needed on libreoffice-5-4

I’m afraid that is FUD. I installed 5.4 RC1 on Windows XP SP3 and it
ran just fine.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: minutes of ESC call ...

[Christian Lohmaier]

Hi *,

On Sat, Jun 10, 2017 at 7:12 PM, probono  wrote:
>
>> no real need for Linux portable edition
>> tar-ball can be unzipped
>
> So can the AppImage:
> ./some.AppImage --appimage-extract

The point was that the linux builds don't have any external
dependencies that are not trivial/already fulfilled by virtually any
linux distribution.

The idea of having "one" package only (and not having people install
additional stuff just to run the package they were originally trying
to install) is solved already for LO.

> An AppImage has the added benefit that it does not have to be
> unpacked, because it mounts itself, which is a very fast operation and
> is space-efficient.

might be space-efficient but of course can also have performance
impact. And not space efficient on the side of those distributing it
without throwing away the modularity re languages.

> The discussion so far is missing AppImageUpdate zsync-based binary
> delta updates, which means that you can do from daily build to daily
> build by just downloading the few MB that actually have changed.

For this kind of usecase, we have bibisect repositories...

https://gerrit.libreoffice.org/#/admin/projects/?filter=bibisect

So bottom line: I'm not being sold.  I don't see a real benefit compared to a

for i in *rpm; do rpm2cpio $i | cpio -idmv ; done

or the tarball/instdir-only distribution like it is done for the debug build.

For other software packages it might have some benefits, but as it was
mentioned that appimage doesn't seem to take care of
dependencies/baseline stuff, the benefit of appimage as a whole is
unclear to me.

chmod +x and run vs unpack and run isn't a real difference, and
definitely no selling point, esp. with the removed flexibility
regarding the l10n/help packages.

ciao
Christian
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: minutes of ESC call ...

[probono]

Hello, AppImage developer here. May I quickly add my perspective:

> is there a central app-store / location to find appimages ?

One objective for the AppImage format is to have a single downloadable
file for Linux that can be provided on the original (upstream)
project's download pages, next to EXE (Windows) and DMG (macOS) files,
and not rely on any central gatekeeper such as a distribution, or a
store. That being said, anyone can make a "directory" of AppImages.
The AppImage project maintains a list of known AppImages on
https://github.com/AppImage/AppImageKit/wiki/AppImages, and there are
sites like https://www.openDesktop.org/ that collect software,
including AppImages.

> if 2 people use it – build it themselves pwrt

On http://linux-appimages.org the inofficial LibreOffice AppImage was
the download #1 within just a few days of being uploaded. And that is
while this site has not been advertised or announced so far. So I'd
assume there is quite some interest.

> how large is it?

The AppImage of the latest daily build with all languages and help
files is 271 MB when stripped. I used
find LibreOfficeDev.AppDir/ -type f -executable -or -name *.so* -exec
strip {} \;

> If infra doesnt want to host the appimages, Antonio can host them

It is strongly advised that users get AppImages - and, for that
matter, any software, even on Windows and macOS - from the official
projects and not from "random" download sites. (Yes I know who Antonio
is and I trust him, but we can't expect the average user to know.)

> chmod +x "

This is a Unix security feature. You can set the executable bit from
the properties window of most (all?) desktop environments. With th
increasing popularity of AppImages, it is to be expected that desktop
environments will handle ELF files with missing executable bits more
intelligently (i.e., ask the user what to do).

> no real need for Linux portable edition
> tar-ball can be unzipped

So can the AppImage:
./some.AppImage --appimage-extract

An AppImage has the added benefit that it does not have to be
unpacked, because it mounts itself, which is a very fast operation and
is space-efficient.

The discussion so far is missing AppImageUpdate zsync-based binary
delta updates, which means that you can do from daily build to daily
build by just downloading the few MB that actually have changed. This
is much, much faster, easier, and more efficient than what is
currently in place. I could imagine this to be especially valuable to
testers, who want the latest daily build every day.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: minutes of ESC call ...

[Stephan Bergmann]

On 05/21/2017 01:22 PM, Chris Sherlock wrote:
[...]
some of them I just didn’t notice the message on 
gerrit

[...]

I routinely add comments to already merged Gerrit changes, assuming that 
authors and reviewers will see the corresponding mails Gerrit sends out 
to them.  If this is generally considered problematic, please let me know.


In terms of whitespacing causing issues in git archaeology, I thought 
git had options to help with this sort of thing, so if that’s a major 
issue then is there something stopping us from using this?


I don't think it's a major issue, just a minor nuisance (for stuff like 
seemingly randomly changing " {" to "\n{").  But even minor nuisances 
can pile up, and while git does have clever options to mitigate some of 
this, you need to remember to use those options, etc.

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: minutes of ESC call ...

[Chris Sherlock]

> On 19 May 2017, at 1:02 am, Michael Meeks  wrote:
> 
> * Commit Access
>+ Cosmetic change issues – churning code without much benefit
>   + asked to avoid this, but this continues.
>+ write a last warning ? (Michael)
>   + always a balance between cosmetic and functional changes (Miklos)
>  + might help.
>   + ok with last warning (Stephan)
>   => do that (Michael)

Warning received. FWIW, I was working through the underlying codebase, and I’ve 
been focussing on unit tests and looking at how the code works for my book, 
some of this code made my eyes bleed but I understand this is controversial 
enough for a warning. 

In my defence, I’ve been attempting to fix up unit test code, but I acknowledge 
I’ve made a number of errors along the way. Some of them have been unforced, 
some of them I just didn’t notice the message on gerrit, and others I just 
didn’t realise it was controversial or even problematic. Not many folks look at 
the OSL codebase from what I could see, and there are some issues that I’ve 
noticed as I’ve read the code. 

In terms of whitespacing causing issues in git archaeology, I thought git had 
options to help with this sort of thing, so if that’s a major issue then is 
there something stopping us from using this? If it’s just a style issue, again 
in my (partial) defense there were things like a function that was completely 
unindented. Surely nobody is all that upset that I indented that?

Anyway, all that said - I acknowledge the issue and I’ll submit any changes to 
gerrit. I’ve tried to bunch up the changes in one go as was requested of me as 
well. 

Chris___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: minutes of ESC call ...

[Eike Rathke]

Hi,

On Thursday, 2017-05-18 16:02:51 +0100, Michael Meeks wrote:

> AI:  + ask Osvaldo for an agenda (Eike)

Agenda is now available at
https://wiki.documentfoundation.org/Hackfest/Perugia2017#Agenda

  Eike

-- 
LibreOffice Calc developer. Number formatter stricken i18n transpositionizer.
GPG key 0x6A6CD5B765632D3A - 2265 D7F3 A7B0 95CC 3918  630B 6A6C D5B7 6563 2D3A
Care about Free Software, support the FSFE https://fsfe.org/support/?erack


signature.asc
Description: PGP signature
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: minutes of ESC call ...

[Eike Rathke]

Hi,

On Thursday, 2017-05-11 15:44:56 +0100, Michael Meeks wrote:

> + openhub statistics (2001-01-01), -1(-1) people did -1(-1) commits in 12 
> month in -1(-1) lines of code
>  + Is that really so ? -1 lines is a lot ...

Currently https://www.openhub.net/p/libreoffice says

30 Day Summary
Apr 1 2017 — May 1 2017
1216 Commits
79 Contributors

12 Month Summary
May 1 2016 — May 1 2017
15733 Commits
Down -2331 (12%) from previous 12 months
270 Contributors
Down -30 (10%) from previous 12 months

However, OpenHub notoriously being a source of not updated data (and now
maybe an API change so all those -1 values?), I propose we
(additionally) use the GitHub data from
https://github.com/LibreOffice/core/pulse/monthly

Excluding merges, 85 authors have pushed 1,279 commits to master and
1,932 commits to all branches. On master, 5,591 files have changed and
there have been 111,775 additions and 71,331 deletions.


API doc at https://developer.github.com/v3/repos/statistics/

For example, commits last 52 weeks daily (no author count though)
curl -i https://api.github.com/repos/LibreOffice/core/stats/commit_activity
piped through
awk -e '/^ +"total": [[:digit:]]+,$/ 
{if(++i>=48){n+=substr($2,1,length($2)-1)}} END{print "Commits: " n}'

gives the number of commits of the last 4 weeks plus days of current
week (currently 1339).
Note this awk scriptlet works only for unauthenticated (limited to 60
per hour per IP) API queries as otherwise the JSON data is all on one
line..

The example uses the source data of graphs with commits daily / weekly / 52 
weeks
https://github.com/LibreOffice/core/graphs/commit-activity

  Eike

-- 
LibreOffice Calc developer. Number formatter stricken i18n transpositionizer.
GPG key 0x6A6CD5B765632D3A - 2265 D7F3 A7B0 95CC 3918  630B 6A6C D5B7 6563 2D3A
Care about Free Software, support the FSFE https://fsfe.org/support/?erack


signature.asc
Description: PGP signature
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: minutes of ESC call ...

[Xisco Fauli]

Hi,


> * crash reporter news (Xisco)
> + http://crashreport.libreoffice.org/stats/?days=128 
> + http://crashreport.libreoffice.org/stats/version/5.3.2.2 
> + 3384 (last 7 days)
> + http://crashreport.libreoffice.org/stats/version/5.2.6.2 
> + 2487 (last 7 days)
> + GDI resource starvation
> + now have a way to reprocue that: font rendering leakage
> + https://bugs.documentfoundation.org/show_bug.cgi?id=106265 
> + thanks to <>
> + when fixed, should nail some of our top issues.
Could this bug [1] be also related to the GDI problem ?
I can open it on Linux but not on Windows, and I'm getting the 'bad
allocation' error as well.
With both bugs, I tried to monitor the GDI objects with a tool called
GDIView but the number of GDI didn't increase while reproducing the crashes.

[1] https://bugs.documentfoundation.org/show_bug.cgi?id=98558

Regards

-- 
Xisco Faulí
Libreoffice QA Team
IRC: x1sc0


___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: minutes of ESC call ...

[David Tardon]

Hi,

On Thu, Apr 06, 2017 at 08:22:04AM +1000, Chris Sherlock wrote:
> > On 31 Mar 2017, at 10:59 pm, David Tardon  wrote:
> > 
> >> On Thu, Mar 30, 2017 at 04:08:18PM +0100, Michael Meeks wrote:
> >> * Crashtest update (Caolan)
> >>+ Google / ossfuzz: 24 fuzzers active now, unchanged
> >>+ not added any more tests – existing giving out enough noise
> >>+ lots of horsepower: they are also testing for local leaks & hangs
> >> + previously ignoring those; lots in this category.
> >>+ fast-hangs are more interesting than timeout – but fixing ...
> > 
> > As I missed the call yesterday...
> > 
> > I've started adding DLP libraries to oss-fuzz. There are 2 active fuzzers 
> > so far: for libmspub and OLE2 parser in librevenge. I have
> > submitted pull requests for 3 more: libcdr, libpagemaker and libwpd. 
> > Another 2, libwpg and libvisio, are in progress. I plan to add all the
> > libraries ultimately (if Google allows :-)
> > 
> > The yield is rather low, which is good. After all, the libraries have been 
> > fuzzed quite extensively in the past...
> > 
> > D.
> 
> Ah! After months (a year or more?) of being away from LO I noticed a whole 
> bunch of fuzzing files... that's amazing work! A real boon for LibreOffice 
> David, great work.

Actually the fuzzers in LibreOffice are Caolan's work. Fuzzers for DLP
libs are in the libs themselves.

> Is there a wiki page on how to use and integrate fuzzing? 

Nothing LibreOffice-specific, no. You can look at
https://github.com/google/oss-fuzz/blob/master/docs/new_project_guide.md
and bin/oss-fuzz-build .

D.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: minutes of ESC call ...

[Chris Sherlock]

Sent from my iPhone

> On 31 Mar 2017, at 10:59 pm, David Tardon  wrote:
> 
>> On Thu, Mar 30, 2017 at 04:08:18PM +0100, Michael Meeks wrote:
>> * Crashtest update (Caolan)
>>+ Google / ossfuzz: 24 fuzzers active now, unchanged
>>+ not added any more tests – existing giving out enough noise
>>+ lots of horsepower: they are also testing for local leaks & hangs
>> + previously ignoring those; lots in this category.
>>+ fast-hangs are more interesting than timeout – but fixing ...
> 
> As I missed the call yesterday...
> 
> I've started adding DLP libraries to oss-fuzz. There are 2 active fuzzers so 
> far: for libmspub and OLE2 parser in librevenge. I have
> submitted pull requests for 3 more: libcdr, libpagemaker and libwpd. Another 
> 2, libwpg and libvisio, are in progress. I plan to add all the
> libraries ultimately (if Google allows :-)
> 
> The yield is rather low, which is good. After all, the libraries have been 
> fuzzed quite extensively in the past...
> 
> D.

Ah! After months (a year or more?) of being away from LO I noticed a whole 
bunch of fuzzing files... that's amazing work! A real boon for LibreOffice 
David, great work.

Is there a wiki page on how to use and integrate fuzzing? 

Chris
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: minutes of ESC call ...

[David Tardon]

On Thu, Mar 30, 2017 at 04:08:18PM +0100, Michael Meeks wrote:
> * Crashtest update (Caolan)
> + Google / ossfuzz: 24 fuzzers active now, unchanged
> + not added any more tests – existing giving out enough noise
> + lots of horsepower: they are also testing for local leaks & hangs
>  + previously ignoring those; lots in this category.
> + fast-hangs are more interesting than timeout – but fixing ...

As I missed the call yesterday...

I've started adding DLP libraries to oss-fuzz. There are 2 active
fuzzers so far: for libmspub and OLE2 parser in librevenge. I have
submitted pull requests for 3 more: libcdr, libpagemaker and libwpd.
Another 2, libwpg and libvisio, are in progress. I plan to add all the
libraries ultimately (if Google allows :-)

The yield is rather low, which is good. After all, the libraries have
been fuzzed quite extensively in the past...

D.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Minutes of ESC call: 2017-03-02

[Stephan Bergmann]

On 03/03/2017 01:01 PM, Khaled Hosny wrote:

On Fri, Mar 03, 2017 at 11:41:09AM +0100, Jan Holesovsky wrote:

 + community edition IDE can't be used until you register
 + E-mail + Account on MS stuff...
 + only blocks the IDE, not compiler.


Though the UI suggests this (no option to skip) when I closed that small
window, it continued with other steps and the IDE showed up just fine (I
didn’t try to use it, though).


At least external/lcms2/ExternalProject_lcms2.mk tries to upgrade some 
vcxproj file, and that is known to cause 'make' to fail without a useful 
error message if VS is not properly registered (after a 30 day trial 
period, IIUC).

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Minutes of ESC call: 2017-03-02

[Khaled Hosny]

On Fri, Mar 03, 2017 at 11:41:09AM +0100, Jan Holesovsky wrote:
>  + community edition IDE can't be used until you register
>  + E-mail + Account on MS stuff...
>  + only blocks the IDE, not compiler.

Though the UI suggests this (no option to skip) when I closed that small
window, it continued with other steps and the IDE showed up just fine (I
didn’t try to use it, though).

Regards,
Khaled
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: minutes of ESC call ...

[Eike Rathke]

Hi,

On Thursday, 2017-02-16 15:43:18 +, Michael Meeks wrote:

> + Most Pressing Bugs: http://tdf.io/mostressingbugs
>   + Older:
> + Crash in: `anonymous 
> namespace'::ScCaptionCreator::UpdateCaptionPos()
> + 
> https://bugs.documentfoundation.org/show_bug.cgi?id=105667
> + has been bisected, would love Eike to take a look at it 
> (?)

Fixed and gerrit reviews pending for 5-3, 5-2 and 5-2-6

  Eike

-- 
LibreOffice Calc developer. Number formatter stricken i18n transpositionizer.
GPG key "ID" 0x65632D3A - 2265 D7F3 A7B0 95CC 3918  630B 6A6C D5B7 6563 2D3A
Better use 64-bit 0x6A6CD5B765632D3A here is why: https://evil32.com/
Care about Free Software, support the FSFE https://fsfe.org/support/?erack


signature.asc
Description: PGP signature
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: minutes of ESC call ...

[Eike Rathke]

Hi,

On Thursday, 2017-02-16 15:43:18 +, Michael Meeks wrote:

> + Most Pressing Bugs: http://tdf.io/mostressingbugs
> + New:
> + Pivot crashes Calc
> + 
> https://bugs.documentfoundation.org/show_bug.cgi?id=105858
> + SC_DPOUT_MAXLEVELS query ...
> + User can’t share the document. I can send it privately 
> if needed
> + quite old - back to 3.5 - quite rare to reproduce.
> + would love input from Eike on what is going on ?
> + document sent to Julian & so on.

Fixed and gerrit reviews pending for 5-3, 5-2 and 5-2-6

  Eike

-- 
LibreOffice Calc developer. Number formatter stricken i18n transpositionizer.
GPG key "ID" 0x65632D3A - 2265 D7F3 A7B0 95CC 3918  630B 6A6C D5B7 6563 2D3A
Better use 64-bit 0x6A6CD5B765632D3A here is why: https://evil32.com/
Care about Free Software, support the FSFE https://fsfe.org/support/?erack


signature.asc
Description: PGP signature
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: minutes of ESC call ...

[Khaled Hosny]

On Thu, Feb 16, 2017 at 09:27:46PM -0700, slacka wrote:
> I really hope that hour search was a bad joke. Google "Download VS 2013" and
> the first link is the download link for the installer.

Did you check the link? It gives you a generic download page that only
offer the latest version.

Regards,
Khaled
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: minutes of ESC call ...

[slacka]

VS 2015 has much better support for Support For C++11/14 Features

https://msdn.microsoft.com/en-us/library/hh567368.aspx

When VS 2013 is depreciated, we can probably remove some ugly  IFDEFs. 

I really hope that hour search was a bad joke. Google "Download VS 2013" and
the first link is the download link for the installer. When I was bisecting
some old regressions, I had no issues finding or downloading VS 2012 either. 



--
View this message in context: 
http://nabble.documentfoundation.org/minutes-of-ESC-call-tp4208111p4208180.html
Sent from the Dev mailing list archive at Nabble.com.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: minutes of ESC call ...

[Khaled Hosny]

On Thu, Feb 16, 2017 at 03:43:18PM +, Michael Meeks wrote:
> AI: + test build configuations (Norbert)
> + Is there any gain of functionality with 2015 ?

Not a gain in functionality, but VS 2015 is much easier to find on MS
website than 2013, last time I hat to setup a Windows machine (a couple
of months ago or so) it took me probably an hour to find the 2013
installer.

Regards,
Khaled
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: minutes of ESC call ...

[Michael Meeks]

Hi David,

On 27/01/17 06:07, David Ostrovsky wrote:
> On Thu Jan 26 15:49:52 UTC 2017, Michael Meeks wrote:
>>+ love a queue that auto-merged when CI succeeds (Michael)
> 
> The missing bits for that feature were finalized and merged during
> recent Gerrit hackathon and will be included in the upcoming release
> 2.14. ETA is June 2017.
> 
> https://gerrit-review.googlesource.com/#/c/79760/

Awesome =)

> I have another topic, updating our gerrit instance to 2.13.5,
> from 2.11.8. There are a lot of improvements.

Sounds like we should discuss that at FOSDEM =)

Thanks !

Michael.

-- 
michael.me...@collabora.com <><, Pseudo Engineer, itinerant idiot
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: minutes of ESC call ...

[Zolnai Tamás]

Hi,

> * TDF / Budgeting / Brainstorming (Thorsten)
> + checkout spreadsheet:
> https://demo.collaboracloudsuite.com/tdf/index.php/apps/richdocuments/index#719_%2FESC%20minutes
>  + currently ranked by highest score
>  + interesting ranking, thanks for rating.

When will these scores be public? I'm interested how ranking looks like.

Thanks,
Tamás
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: minutes of ESC call ...

[Tommy]

Michael Meeks wrote:



> 


* Release Engineering update (Christian)
+ 5.2.5 release status
+ announced today





https://wiki.documentfoundation.org/Releases/5.2.5/RC1

this page is still empty.
the list of fixed bugs has not been published yet.
Tommy

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: minutes of ESC call ...

[Jan-Marek Glogowski]

Am 27.01.2017 um 07:07 schrieb David Ostrovsky:
> It would be also cool, if you could look into new and shiny gerrit UI,
> based on JavaScript Polymer framework, and provide feedback. You can
> see the new UI in action upstream by switching in footer to new UI.
> Only change screen is implemented for now. All diffs on one page is
> already implemented:
> 
> https://gerrit-review.googlesource.com/

Generally I like the new UI - if just for the - per file expandable -
inline diff :-) But switching the "info" and "commit message" frames
produces a lot of unused / white area on the right, and uses more
precious vertical space.
Especially since the left "info" frame doesn't expand much horizontally,
so can't / won't display multiple reviewers in one row, but instead the
commit message expands, which almost ever has a fixed maximum width.

I first had a look at

https://gerrit-review.googlesource.com/c/95455/?polygerrit=1

but it's probably event better to see, if you check

https://gerrit-review.googlesource.com/c/94813/?polygerrit=1

Now there is some of the white space used by the relation chain.
Just decrease the browser horizontally.

To save some vertical space it would also help to merge Reviewers,
Code-Review and Verified into a table, so this won't duplicate name
lists, like:

Reviewer | Verified | Code
Me   |   +1 |  +1
You  |  |  -1

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: minutes of ESC call ...

[Samuel Mehrbrodt]

* Enable creating backups of user profile in release builds (Bubli)
 + part of profile safe mode feature
 + 2 backups (zip archives) of user profile kept around in non-release 
builds
 + user profile can be restored from those backups in safe mode
 + a patch from Samuel M: https://gerrit.libreoffice.org/#/c/33584/1
+ activates this in release builds.
+ untested in practice so far, risk level unclear
 + feature is shown in the UI ? (Michael)
+ restore from backup always inactive in 5.3 – no backups generated.
+ don’t know how big they can grow in real life.
 + users can enable this manually – but unsure if it should be for everyone.
 + drag and drop to the gallery can create big user directories (Heiko)
+ warning taking a backup can consume 1Gb for big galleries.
+ could we ask for confirmation at a high level ?
+ Comic Author has 500 images there
+ in the ini file can disable the backups and choose copy count 
(Bubli)
 => enable by default for 5.3.1


The bootstrap setting "SecureUserConfigMode" lets you control what is 
included in the backup. It accepts a number in the range 0..2.


You can read here what that means: 
http://opengrok.libreoffice.org/xref/core/comphelper/source/misc/backupfilehelper.cxx#2662

So in the default configuration ("1") galleries would also be included.

My suggestion is to remove galleries from that list and then enable it 
for 5.3.1 as you discussed.
We should be prepared to get bug reports about slowness at startup 
though as the backup is done at every launch of LO (if I remember 
correctly).


Samuel
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: minutes of ESC call ...

[Xisco Fauli]

Hi,


El 13/01/17 a les 15:03, Michael Meeks ha escrit:

* Release Engineering update (Christian)
 + 5.2.5 RC1 schedule acceleration ?
 + fixes for both regressions in 5.2
 + builds done, tagging finished, up-loading underway.
 + should we do an RC1 release as final ?
   + Markus’ patches in the release & sensible (Xisco)
   + concern wrt. rushing things (Thorsten)
   + does waiting one week make sense ? (Xisco)
=> test over the weekend – recide RC2 or release on Tuesday (Xisco)
I haven't heard any concern about crashes in 5.2.5.1 over the weekend so 
I believe we can give a go to the final release.


Regards

--
Xisco Faulí
Libreoffice QA Team
IRC: x1sc0

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: minutes of ESC call ...

[Xisco Fauli]

Hello all,


+ new issue created as MAB tdf#105259
+ Beluga: can’t be fixed before 5.3
+ asking for help with glade (Heiko)
+ even the simple reverting is risky (Xisco)
+ we need to fix the dialog (Heiko)
+ fixing and testing in one week not possible (Xisco)
=> revert the patch in 5.3 & fix in 5.4.
AI:do the revert and do it in 5.4 (Xisco)
in yesterday's meeting, we agreed to revert this patch 
62a94dcf0c750e335d6ce272d8a5df9813910d5a in 5.3.
However, I've just seen Tomaž submitted two new patches to master 
related to this problem: 00db9f51215d11da3b27685a39ec940ecd65e387 and 
e6d7d737522124350a17a3cfdee055f03200a274, and according to a comment 
written by Buovjaga in tdf#105259, it seems to fix all problem 
introduced by 62a94dcf0c750e335d6ce272d8a5df9813910d5a.


So I would to like to ask if any developer can review those new patches 
and if they look good, push them to 5.3 instead of reverting 
62a94dcf0c750e335d6ce272d8a5df9813910d5a as we agreed yesterday.


Regards

--
Xisco Faulí
Libreoffice QA Team
IRC: x1sc0

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: minutes of ESC call ...

[Bjoern Michaelsen]

Hi,

On Fri, Dec 09, 2016 at 11:45:56AM +0100, Jan Iversen wrote:
> Now we are getting very close to my x-mas wishlist.
> 
> the current json files made by gbuildjson misses 2 things:
> - objective C++ (and some other language) files are not accounted for

Thats trivial to add and left as an excerise to the reader.

> - there are no dependency structure (as provided by running “make -d”)

There is: linked libs and linked static libs provide that for a 1 feet
view. Of course its a simplification, because that is the whole point of the
gbuildtojson execise: Leaving out all the cornercases and shortcuts to have
something simplified that can be translated.

> - the gb_macros do not make the C++ program, but makes a simple echo with an 
> identifier

That will likely explose on some platforms sooner rather than later due to
shell length limits. There is a reason we use var2file, the reasons for which
can be painfully exermined in the git log.

> - make is called with “make -d gbuildtojson | gbuildjson.exe

That will produce huge amounts of output and thus be very slow. Also it
reintroduces parsing GNU make output directly, which we are by now more than
aware to be fragile and prone to breaking. Better to cause the output of "make
gbuildtojson" to provide the needed info properly. The whole point of
gbuildtojson is to have some stable output and NOT be broken by (make-)version
specific behaviour.

> With that change the json files contains enough information to e.g. generate
> a new set of makefiles without macros.

So, generate makefiles from makefiles, because ... well, why? We have so far
successfully avoided the common autotools-style madness of creating generated
intermediate makefiles. Debugging those usually is a huge PITA.

Doing that is a kludge that was historically needed in the early 1990 as there
where a bazillion incompatible makes that where broken in many different ways.
Anyone having to deal with it hated it and will until the end of their life.
Those days are over and we can depend on GNU make being available (or portable)
everywhere. Thus generated makefiles should really really be avoided.

As of now, the only valid reason left for generated build files is the 
performance
of some backend tools (e.g. ninja) by having better caching/intermediate 
formats for
the (huge) dependency graph we produce. Ninja alone wont replace GNU make, so
we would still be using both, and we would need good reasons to justify the
inevitable "my ninja build does weird stuff, let me try to debug 200KLOC of
generated build instructions we threw at it"-fun it will yield.

Hint: Thus if we consider ninja as a backend for the build system with
performance as argument to use it, we would need some good hard cold number on
how much better ninja is at that.

However, this is shifting goalposts -- the original argument was about how hard
it is for a newcomer to get an initial build setup on Windows (still) and none
of this is helping with any of that (Steamlining LODE and documentation would,
however).

Best,

Bjoern
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: minutes of ESC call ...

[Thorsten Behrens]

Katarína Behrens wrote:
> I'm slightly reluctant to make this 5.3 late feature, not because of
> the impact on translations (which I clarified in another e-mail to
> Cloph & Olivier) but because of the impact on how help is packaged
> on all 3 platforms for TDF builds and Linux distributions.
> 
Right - and the question is, what does it buy us anyway for 5.3, given
that new helpcontent / extra images will only happen on master after
string freeze?

Cheers,

-- Thorsten


signature.asc
Description: Digital signature
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: minutes of ESC call ...

[Khaled Hosny]

On Thu, Dec 08, 2016 at 04:56:07PM +, Michael Meeks wrote:
>   + who else needs a Mac ? ... answers on a post-card.

I think I can make use of one, if it can get here easily. I currently
use the same Mac laptop for both Linux and Mac development, not the most
productive setup.

Regards,
Khaled
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: minutes of ESC call ...

[Bjoern Michaelsen]

Hi,

On Fri, Dec 09, 2016 at 08:57:03PM +, Michael Meeks wrote:
>   Sure - question is if we want to check all the un-buildable binaries
> into a git repository; but we can do of course if it saves having a
> shell to download things.

Well, we could have the binaries in a submodule, so as not to pollute sane
environemnts. Maybe?

OTOH, since we are abondoning good taste anyway: We could also have all the
cygwin install as an image download, instead of bothering with installers
and setups -- AFAICR cygwin can be dumped pretty easily anywhere without much
need for "installers". Just mirroring a fixed cygwin install without bothering
for installer etc. might already kill a lot of the hurtful degrees of freedom.
 
>   For me at least, none of that is relevant. We can pre-generate all of
> that and include it pre-built inside the 'something' that is downloaded.

You will spend more time discussing why e.g. (naive, not fully intentional) UNO
changes break the world in this setup than you will gain, I guess. I dont
think the target audience is aware at all about UNO or what "you cant do
incompatible changes" would mean. Note UNO is just one example here.
 
>   Sure there are pain-points; and it is a rather artificial setup that is
> proposed - a newbie / starting developer setup. Having said that - you
> can get a -very- long way with just editing C++ files in a tree with
> pre-build python, ICU, etc. etc.

You can get a long way with just editing C++ files in the gerrit UI. Or with
Clophs pre-build remote Hackfest VM (which should probably include an IDE and
solutions e.g. kdevelop now). The question is what we achieve with that. There
seem to be two goals here:

1/ getting a newcomer to create their first patch ASAP
2/ becoming a somewhat selfsufficient contributor to LibreOffice

For 2/ getting a local Visual Studio setup might help a bit, while for 1/ both
Hackfest VMs and gerrit webediting are a lot better suited. Then again, we dont
see a lot of failure between 1/ and 2/, but we are hearing stories of untapped
possibilities that dont even get to 1/.

>   Sure - and this then becomes an incremental task ;-) -iff- doing this
> generates interest from lots of new developers, which it might, then I
> suspect we get a set of manpower with motivation to make more and more
> of the code easily accessible on Windows ;-)

Fighting the dependency explosion is valuable in itself: Mostly because
"migrate tooling to be more native" is quite EasyHack-suitable and there might
be talent able to do it that wouldnt be able to contribute to core development
anyway ...

Best,

Bjoern
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: minutes of ESC call ...

[Michael Meeks]

Hi Bjoern,

On 08/12/16 18:40, Bjoern Michaelsen wrote:
>>  * download 'something'
> (actually, Visual Studio can directly clone git repos, so
>  manual downloads shouldnt be needed)

Sure - question is if we want to check all the un-buildable binaries
into a git repository; but we can do of course if it saves having a
shell to download things.

>>  * click the green triangle to debug ;-)
> 
> Certainly works for kdevelop and used to work for MSVS.

Great - so we're nearly there.

>>  Where of course that 'something' would need to be constructed by some
>> tinderbox / slave, and (ideally) contain everything not easily buildable
>> with the IDE already pre-built =)
> 
> Ok, who is going to finally kill scp2, the horribly icon-theme scriping, UNO
> registry generation plumbing etc. for good? (With kill=port to plain C++ 
> tooling).

For me at least, none of that is relevant. We can pre-generate all of
that and include it pre-built inside the 'something' that is downloaded.

>>  Personally I'd see this as an entry mode: once people have the
>> satisfaction of seeing their work 'working' they can graduate to
>> installing cygwin, and . Clearly there would
>> be nothing authoritative about it etc.
> 
> That would assume to use a pregenerated autoconf output then (as autoconf need
> essentially all of POSIX and then some). Possibly -- but not without its own
> pain points (ask any Sun engineer, this is was how StarOffice builds were 
> like).

Sure there are pain-points; and it is a rather artificial setup that is
proposed - a newbie / starting developer setup. Having said that - you
can get a -very- long way with just editing C++ files in a tree with
pre-build python, ICU, etc. etc.

>>  AFAICS - there -should- also be no need for cygwin, LODE, or anything
>> else in this world ;-) just a single download.
> 
> Well, we sneakily use various bits of sed/gawk/gperf/perl/python/zip/tar/... 
> in
> various corners of the build.

Sure - and this then becomes an incremental task ;-) -iff- doing this
generates interest from lots of new developers, which it might, then I
suspect we get a set of manpower with motivation to make more and more
of the code easily accessible on Windows ;-)

ATB,

Michael.

-- 
michael.me...@collabora.com <><, Pseudo Engineer, itinerant idiot
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: minutes of ESC call ...

[Katarina Behrens]

Hello world

> + Late features:
> + separating images and icons for help modules (Olivier, Bubli)
> + still waiting for Olivier's sample string change to write
> the script. + we need to see the impact on translators.

I'm slightly reluctant to make this 5.3 late feature, not because of the 
impact on translations (which I clarified in another e-mail to Cloph & Olivier) 
but because of the impact on how help is packaged on all 3 platforms for TDF 
builds and Linux distributions.

For complete separation, every offline help package will now need to come with 
extra zip archive with images. This is a non-trivial change and I don't think 
it's fair to expect distro packagers to do that kind of work this late in the 
game. 

For partial separation, a zip archive with help images can be shipped along 
with icon themes. The only difference is that the images (misc illustrations 
and new screenshots) will have moved from core to help git repository. This is 
presumably less work for the packagers, but it adds some load still ... 

-- 

Katarina Behrens

Softwareentwicklerin LibreOffice
–––
CIB software GmbH
Geschäftsstelle Hamburg
Flachsland 10
22083 Hamburg
–––
T +49 (40) / 28 48 42 -235
F +49 (40) / 28 48 42 -100

katarina.behr...@cib.de
www.cib.de
–––
Sitz: München
Registergericht München, HRB 123286
Geschäftsführer: Dipl.-Ing. Ulrich Brandner
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: minutes of ESC call ...

[Jan Iversen]

> On 9 Dec 2016, at 11:35, Bjoern Michaelsen  
> wrote:
> 
> Hi, 
> 
> some additional thoughts below:
> 
> On Thu, Dec 08, 2016 at 07:40:40PM +0100, Bjoern Michaelsen wrote:
>>> AFAICS - there -should- also be no need for cygwin, LODE, or anything
>>> else in this world ;-) just a single download.
>> Ok, who is going to finally kill scp2, the horribly icon-theme scriping, UNO
>> registry generation plumbing etc. for good? (With kill=port to plain C++ 
>> tooling).
>> [...]
>> Well, we sneakily use various bits of sed/gawk/gperf/perl/python/zip/tar/... 
>> in
>> various corners of the build. Killing those and replacing them with GNU make
>> and plain C++ would be good, but is quite a thankless effort. I agree though 
>> it
>> would be appreciated to make the build easier to bootstrap.
>> 
>> tl;dr: First kill the POSIX deps sprinkled all over the repo[1], building a 
>> bit of
>> C++ libs isnt the issue.  All the plumbing around it is.
> 
> On a more positive and actionable note: With C++11 having regex[1] that
> certainly is possible and e.g. Perl-to-C++11 might even be some EasyHacks.
> Limiting the tools used in the build system to C++11, GNU make and basic
> cross-plattform busybox[2] might be a starting point and allow all of:
> 
> - migrating to e.g. using ninja as backend
> - migrating away from GNU make (via gbuildtojson and manually recreating the
>  bazillion configure-based conditional we have in Makefiles)
> - simple bootstrapping on Windows without the need for cygwin or LODE 
Now we are getting very close to my x-mas wishlist.

the current json files made by gbuildjson misses 2 things:
- objective C++ (and some other language) files are not accounted for
- there are no dependency structure (as provided by running “make -d”)

I have been experimenting with a variant of gbuildtojson:
- the gb_macros do not make the C++ program, but makes a simple echo with an 
identifier
- make is called with “make -d gbuildtojson | gbuildjson.exe
- the C++ program is changed to understand the “make -d” dependency structure, 
and of course the echo statements.

With that change the json files contains enough information to e.g. generate a 
new set of makefiles without macros.
 
> 
> So while I am reluctant to replace gbuild as the canonical build _right now_,
> Im all for killing the custom tooling based on all of coreutils and Perl in
> gbuild (and replace it with plain C++11 ... and maybe busybox for a start).
> Once that happened, we can consider all the options on where to carry the 
> build
> system from there. But locking in one of those options now, with all the
> tooling crap still around would be jumping the gun.
> 
> So: Who is going to champion the "kill all Perl in the Build" (for a start) 
> EasyHack?
It is not fair I just complain without also volunteering :-)

That would be something I would like to do, with a little help from the 
experts, and provided Norbert has nothing against it.

have a nice weekend
jan I.

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: minutes of ESC call ...

[Bjoern Michaelsen]

Hi, 

some additional thoughts below:

On Thu, Dec 08, 2016 at 07:40:40PM +0100, Bjoern Michaelsen wrote:
> > AFAICS - there -should- also be no need for cygwin, LODE, or anything
> > else in this world ;-) just a single download.
> Ok, who is going to finally kill scp2, the horribly icon-theme scriping, UNO
> registry generation plumbing etc. for good? (With kill=port to plain C++ 
> tooling).
> [...]
> Well, we sneakily use various bits of sed/gawk/gperf/perl/python/zip/tar/... 
> in
> various corners of the build. Killing those and replacing them with GNU make
> and plain C++ would be good, but is quite a thankless effort. I agree though 
> it
> would be appreciated to make the build easier to bootstrap.
> 
> tl;dr: First kill the POSIX deps sprinkled all over the repo[1], building a 
> bit of
> C++ libs isnt the issue.  All the plumbing around it is.

On a more positive and actionable note: With C++11 having regex[1] that
certainly is possible and e.g. Perl-to-C++11 might even be some EasyHacks.
Limiting the tools used in the build system to C++11, GNU make and basic
cross-plattform busybox[2] might be a starting point and allow all of:

- migrating to e.g. using ninja as backend
- migrating away from GNU make (via gbuildtojson and manually recreating the
  bazillion configure-based conditional we have in Makefiles)
- simple bootstrapping on Windows without the need for cygwin or LODE 

So while I am reluctant to replace gbuild as the canonical build _right now_,
Im all for killing the custom tooling based on all of coreutils and Perl in
gbuild (and replace it with plain C++11 ... and maybe busybox for a start).
Once that happened, we can consider all the options on where to carry the build
system from there. But locking in one of those options now, with all the
tooling crap still around would be jumping the gun.

So: Who is going to champion the "kill all Perl in the Build" (for a start) 
EasyHack?

Best,

Bjoern

[1] http://en.cppreference.com/w/cpp/regex
[2] There are at least two native ports:
https://github.com/rmyorston/busybox-w32
https://github.com/pclouds/busybox-w32
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice