from:"julien2412"

Michael Meeks-5 wrote
> ...
>   Hopefully you would be able to come ?

No need to come since it's easier for me to write (no schedule constraints
for example) and the migration will be done anyway, no need to worry.
Moreover, even if there was a vote I suppose there'll be a large majority
who'll agree with it.
Remark: I wouldn't be able to vote anyway since I'm not a TDF member and
still would't like to because of these kinds of decisions.

My goal was just to thank a lot Luboš and to provide arguments against the
migration. Nevertheless, I already knew the battle, battle against this
censorship (I weigh my words) was lost.

Regards,

Julien




--
Sent from: 
http://document-foundation-mail-archive.969070.n3.nabble.com/Dev-f1639786.html
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: ANN: renaming of master branch to "main" for core repository and submodules (dictionaries, help, translations)

Thorsten Behrens-6 wrote
> ...
> Well. I'm not sure it matters much what you or me read into that word.
> 
> So is there any harm in making that change? Others are doing the work,
> why would we refuse a change that some feel strongly about?
> 
> We're happily accepting changes that re-format code, translate,
> spell-check it etc - one could argue those are cosmetic too, and not
> worth it.
> 
> I'm therefore much in favour of remaining to be welcoming to change,
> and positively accept patches from everyone (unless there's hard
> technical reasons to decline).

Reformating code allows to have homogeneous code and allows to read it more
easily.
Spellcheck is just about trying to respect languages, if not we could also
begin to write like in SMS and it may quickly difficult for non native
English speaker to understand it. (I know that sometimes we must decide
between US and English spell and it's not that important if everybody
understands the meaning of the word).

I'm strongly against this change because it's not just cosmetic, it's
imposing a point of view (Yes I'm doing the same but it's a debate so of
course there are at least 2 points of view), it's kind of new puritanism for
me. Until some months ago, nobody found it wrong to call a "branch master",
now we must remove it just for some people who may consider this offending.
Are there really some stats about this? Would these people feel really bad
about seeing "master" branch? Do I really offend some people when in
bugtrackers I put:
"On pc Debian x86-64 with master sources updated today, " ?

Technical reason to decline: a non 0 technical risk for a real 0 technical
benefit

Again, do you want to rename "Abort", "Command"?
Cars (even eletric ones) generate pollution, would you be agree to remove
any reference to the word "cars" in LO? (I didn't check if there was, it's
just for the example).
Are they bad habits and so you would consider a good evolution to replace
them too?

Julien





--
Sent from: 
http://document-foundation-mail-archive.969070.n3.nabble.com/Dev-f1639786.html
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: ANN: renaming of master branch to "main" for core repository and submodules (dictionaries, help, translations)

Thorsten Behrens-6 wrote
> ...
> The reason is, that language evolves, and bad habits (or metaphors) of
> the past shouldn't be persisted, if we know they are offensive to
> others.

Slavery itself shouldn't persist (badfully in some regions it still exists)
but let's not confound the slavery itself with some words used in different
contexts.

About "master", the expressions "MC"/"Master of Ceremony" in music,
"Master's_degree", "masterplan", "to master something",  are bad habits
too and should be renamed/rephrased?
Should we also remove (burn?) lots of books and republish them after having
processed global autocorrection? (I would even replace "autocorrection" by
"censorship" here)

If you'd ask every people on earch what they may consider offensive, you
could remove lots of words.

Do you also consider we should rename "abort" (because people against
abortion could consider this term offensive) or "command" (because may be
related to slavery too) (as already quoted in my previous comment)?

Julien



--
Sent from: 
http://document-foundation-mail-archive.969070.n3.nabble.com/Dev-f1639786.html
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: ANN: renaming of master branch to "main" for core repository and submodules (dictionaries, help, translations)

Lubos Lunak-2 wrote
> On Wednesday 17 of March 2021, Christian Lohmaier wrote:
>> Hi *,
>>
>> as requested and announced in previous ESC-minutes and infra-call
>> minutes, master branch will be renamed for the LibreOffice core
>> repositories and the submodules used by LibreOffice (dictionaries,
>> help, translations).
> (...)
>  I disagree with the plan.

I had told nothing until now thinking I would be the only person to have
this opinion.

After:
1)
http://document-foundation-mail-archive.969070.n3.nabble.com/Tell-me-Easy-Hack-42782-quot-remove-a-dog-quot-is-a-joke-tt3587827.html#a3588273

(Easy Hack 42782 "remove a dog ! ")

2)
https://cgit.freedesktop.org/libreoffice/core/commit/?id=493ae7a6bb0c3ad50615db0090e7ae8d391bc327
"replace usage of blacklist with denylist" 
and
https://cgit.freedesktop.org/libreoffice/core/commit/?id=abb6c01519a0318d7165dc9dc5b7d185353f93d6
"replace usage of whitelist with allowlist"

Now we must rename "master".
Of course, it's not all 0 risk operation and the technical benefit is 0 +
time consuming. (not as if we had lots of human resources on LO and had very
few bugtrackers to tackle).

Should we expect to replace other things like that? (eg "command" word which
could be misinterpreted too)

Even if it won't change anything and this migration will be done anyway
because marketing and novlang dominate nowadays, THANK YOU A LOT for your
message Luboš!!!

Julien

--
Sent from: 
http://document-foundation-mail-archive.969070.n3.nabble.com/Dev-f1639786.html
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: proposition for patch in CommonSalLayout.cxx

2021-03-09 Thread julien2412

Stanisław Jeśmanowicz wrote
>>
> This is not always the case, because if a platform didn't include
> graphite2 shaper in its HarfBuzz 
> implementaion, you won't have it anyway ( like ./configure
> --with-graphite2=no )
> Even if you set it the shapers list (as in 
> https://cgit.freedesktop.org/libreoffice/core/commit/?id=3cee50476e422e3ed84169cdcbe6bd9883fc9316
> )
> And if graphite2 shaper is implemented, then it will be first (as you can
> see in the harfbuzz code: 
> https://github.com/harfbuzz/harfbuzz/blob/master/src/hb-shaper-list.hh )
> And generally speaking, hard-coded list in such a case disables possible
> new shapers.

Perhaps the goal was indeed to avoid non tested new shapers in LO that could
bring some havoc.
So by hard coding shapers, you're sure you won't have problems.
Now of course, if nobody ever test new shapers, LO will be stuck with old
ones.

Anyway, now you got an account, once you had already submitted your license
(see
https://wiki.documentfoundation.org/Development/GetInvolved#License_statement),
I'll put Khaled in cc, he certainly will bring interesting thoughts here.

Julien



--
Sent from: 
http://document-foundation-mail-archive.969070.n3.nabble.com/Dev-f1639786.html
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: proposition for patch in CommonSalLayout.cxx

2021-03-09 Thread julien2412

Stanisław Jeśmanowicz wrote
> ...
> Thank you for your advice, but getting familiar with gerrit on top of git
> would take some time for 
> me now.
> I hope, that some of your developers could commit this patch for me in vcl
> module.
> It is simple and won't harm anything.
> But people could benefit from it on all platforms that use system's native
> HarfBuzz implementation.
> ...

I can understand you don't have time for gerrit but would it be possible you
submit a license statement?

About this line, I retrieved the initial patches which put this line:
1) earliest
https://cgit.freedesktop.org/libreoffice/core/commit/?id=3cee50476e422e3ed84169cdcbe6bd9883fc9316:
Author: Khaled Hosny 
Date:   Fri Mar 10 16:53:08 2017 +0200

tdf#106466: Use graphite2 shaper first

We want to always prefer Graphite shaping when supported by the font,
which is also what HarfBuzz does by default.

Change-Id: I6670fc03b8e6b3d7e07e1b8e0062880524da1655
Reviewed-on: https://gerrit.libreoffice.org/35046
Tested-by: Jenkins 
Reviewed-by: Khaled Hosny 


2) oldest
https://cgit.freedesktop.org/libreoffice/core/commit/?id=7854d35cd8172b201f1f3ad247860f242e5cb06b
Author: Khaled Hosny 
Date:   Thu Oct 6 04:15:41 2016 +0200

Use HarfBuzz shape plan for a bit more control

This way we control exactly what shapers we use in what order, and as an
extra we can now tell which shaper HarfBuzz ends up using.

Julien



--
Sent from: 
http://document-foundation-mail-archive.969070.n3.nabble.com/Dev-f1639786.html
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: proposition for patch in CommonSalLayout.cxx

2021-03-09 Thread julien2412

Hello,

In addition to what Miklos indicated, I think you may be interested in
https://wiki.documentfoundation.org/Development/GetInvolved.
Indeed, it seems you've already downloaded sources, built and tried to fix a
problem with a patch.
So you only need now a gerrit account and submit your license statement (not
the most difficult).
About the patch itself, I got no expertise so can't tell at all.
In general a patch can be discussed precisely in gerrit.

Julien.



--
Sent from: 
http://document-foundation-mail-archive.969070.n3.nabble.com/Dev-f1639786.html
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: External Data Source in Calc

2021-03-08 Thread julien2412

Hello,

It seems it wasn't maintained at all so we thought about removing it
completely.
see https://bugs.documentfoundation.org/show_bug.cgi?id=139409

Of course, if you want to work on it and fix the bugs listed here:
https://bugs.documentfoundation.org/buglist.cgi?bug_status=UNCONFIRMED_status=NEW_status=ASSIGNED_status=REOPENED_id=1274925=LibreOffice_format=advanced_desc=data%20provider_desc_type=allwordssubstr

don't hesite to "resurrect" it!
But try to focus first on fixing existing bugs related to data provider
before adding it new features.

Julien



--
Sent from: 
http://document-foundation-mail-archive.969070.n3.nabble.com/Dev-f1639786.html
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Questions about ./bin/update_pch.sh

2021-03-06 Thread julien2412

Hello,

I'm trying failing Windows builds by using ./bin/update_pch.sh but it seems
when 1 TB is fixed, another begins to fail.
Also, when relaunching the script, there are always changes (other than the
generating line of course).

What's the trick here? Should I run this script until there are no more
functional changes?

Julien



--
Sent from: 
http://document-foundation-mail-archive.969070.n3.nabble.com/Dev-f1639786.html
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

[SOLVED] Re: Build failure in connectivity/evoab2 [loplugin:refcounting]

2021-03-04 Thread julien2412

Hello Stephan,

I cherry-picked your patch and I confirm LO builds now.
Thank you!

Julien



--
Sent from: 
http://document-foundation-mail-archive.969070.n3.nabble.com/Dev-f1639786.html
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Build failure in connectivity/evoab2 [loplugin:refcounting]

2021-03-03 Thread julien2412

Hello,

On pc Debian x86-64 with master sources updated today, I got:
[CXX] connectivity/source/drivers/firebird/Column.cxx
/home/julien/lo/libreoffice/connectivity/source/drivers/evoab2/NDriver.cxx:106:23:
error: cppu::OWeakObject subclass 'connectivity::evoab::OEvoabConnection'
being managed via raw pointer, should be managed via rtl::Reference
[loplugin:refcounting]
OEvoabConnection* pCon = new OEvoabConnection( *this );
~~^~~~
[CXX] connectivity/source/drivers/firebird/Columns.cxx
[CXX] connectivity/source/drivers/firebird/Connection.cxx
1 error generated.
make[1]: *** [/home/julien/lo/libreoffice/solenv/gbuild/LinkTarget.mk:301 :
/home/julien/lo/libreoffice/workdir/CxxObject/connectivity/source/drivers/evoab2/NDriver.o]
Erreur 1
make[1]: *** Attente des tâches non terminées
/home/julien/lo/libreoffice/connectivity/source/drivers/evoab2/NColumns.cxx:58:26:
error: cppu::OWeakObject subclass 'connectivity::sdbcx::OColumn' being
managed via raw pointer, should be managed via rtl::Reference
[loplugin:refcounting]
OColumn* pRet = new OColumn(
~^~~
1 error generated.
make[1]: *** [/home/julien/lo/libreoffice/solenv/gbuild/LinkTarget.mk:301 :
/home/julien/lo/libreoffice/workdir/CxxObject/connectivity/source/drivers/evoab2/NColumns.o]
Erreur 1
/home/julien/lo/libreoffice/connectivity/source/drivers/evoab2/NTables.cxx:51:26:
error: cppu::OWeakObject subclass 'connectivity::evoab::OEvoabTable' being
managed via raw pointer, should be managed via rtl::Reference
[loplugin:refcounting]
OEvoabTable* pRet = new OEvoabTable(
~^~~
1 error generated.
make[1]: *** [/home/julien/lo/libreoffice/solenv/gbuild/LinkTarget.mk:301 :
/home/julien/lo/libreoffice/workdir/CxxObject/connectivity/source/drivers/evoab2/NTables.o]
Erreur 1
/home/julien/lo/libreoffice/connectivity/source/drivers/evoab2/NDatabaseMetaData.cxx:987:49:
error: cppu::OWeakObject subclass
'::connectivity::ODatabaseMetaDataResultSet' being managed via raw pointer,
should be managed via rtl::Reference [loplugin:refcounting]
::connectivity::ODatabaseMetaDataResultSet* pResult = new
::connectivity::ODatabaseMetaDataResultSet(::connectivity::ODatabaseMetaDataResultSet::eTableTypes);
   
^
/home/julien/lo/libreoffice/connectivity/source/drivers/evoab2/NDatabaseMetaData.cxx:1012:33:
error: cppu::OWeakObject subclass 'connectivity::ODatabaseMetaDataResultSet'
being managed via raw pointer, should be managed via rtl::Reference
[loplugin:refcounting]
ODatabaseMetaDataResultSet* pResultSet = new
ODatabaseMetaDataResultSet(ODatabaseMetaDataResultSet::eTypeInfo);
   
^~
/home/julien/lo/libreoffice/connectivity/source/drivers/evoab2/NDatabaseMetaData.cxx:1059:33:
error: cppu::OWeakObject subclass 'connectivity::ODatabaseMetaDataResultSet'
being managed via raw pointer, should be managed via rtl::Reference
[loplugin:refcounting]
ODatabaseMetaDataResultSet* pResultSet = new ODatabaseMetaDataResultSet(
ODatabaseMetaDataResultSet::eColumns );
   
^~~
/home/julien/lo/libreoffice/connectivity/source/drivers/evoab2/NDatabaseMetaData.cxx:1081:33:
error: cppu::OWeakObject subclass 'connectivity::ODatabaseMetaDataResultSet'
being managed via raw pointer, should be managed via rtl::Reference
[loplugin:refcounting]
ODatabaseMetaDataResultSet* pResult = new
ODatabaseMetaDataResultSet(ODatabaseMetaDataResultSet::eTableTypes);
   
^
4 errors generated.
make[1]: *** [/home/julien/lo/libreoffice/solenv/gbuild/LinkTarget.mk:298 :
/home/julien/lo/libreoffice/workdir/CxxObject/connectivity/source/drivers/evoab2/NDatabaseMetaData.o]
Erreur 1
/home/julien/lo/libreoffice/connectivity/source/drivers/evoab2/NConnection.cxx:120:25:
error: cppu::OWeakObject subclass 'connectivity::evoab::OEvoabCatalog' being
managed via raw pointer, should be managed via rtl::Reference
[loplugin:refcounting]
 OEvoabCatalog *pCat = new OEvoabCatalog(this);
 ~~~^~
/home/julien/lo/libreoffice/connectivity/source/drivers/evoab2/NConnection.cxx:132:17:
error: cppu::OWeakObject subclass 'connectivity::evoab::OStatement' being
managed via raw pointer, should be managed via rtl::Reference
[loplugin:refcounting]
OStatement* pStmt = new OStatement(this);
^~~~
/home/julien/lo/libreoffice/connectivity/source/drivers/evoab2/NConnection.cxx:144:30:
error: cppu::OWeakObject

Re: Local LO build on Raspberry pi 4b doesn't launch

2021-02-20 Thread julien2412

I got this error during build
[CXX] store/source/storcach.cxx
/home/pi/lo/libreoffice/store/source/lockbyte.cxx:701:1: error:
‘store::{anonymous}::MemoryLockBytes::~MemoryLockBytes()’ defined but not
used [-Werror=unused-function]
  701 | MemoryLockBytes::~MemoryLockBytes()
  | ^~~
/home/pi/lo/libreoffice/store/source/lockbyte.cxx:697:1: error:
‘store::{anonymous}::MemoryLockBytes::MemoryLockBytes()’ defined but not
used [-Werror=unused-function]
  697 | MemoryLockBytes::MemoryLockBytes()
  | ^~~
/home/pi/lo/libreoffice/store/source/lockbyte.cxx:561:1: error:
‘store::{anonymous}::MappedLockBytes::~MappedLockBytes()’ defined but not
used [-Werror=unused-function]
  561 | MappedLockBytes::~MappedLockBytes()
  | ^~~
/home/pi/lo/libreoffice/store/source/lockbyte.cxx:556:1: error:
‘store::{anonymous}::MappedLockBytes::MappedLockBytes(const
store::{anonymous}::FileMapping&)’ defined but not used
[-Werror=unused-function]
  556 | MappedLockBytes::MappedLockBytes (FileMapping const & rMapping)
  | ^~~
/home/pi/lo/libreoffice/store/source/lockbyte.cxx:329:1: error:
‘store::{anonymous}::FileLockBytes::~FileLockBytes()’ defined but not used
[-Werror=unused-function]
  329 | FileLockBytes::~FileLockBytes()
  | ^
/home/pi/lo/libreoffice/store/source/lockbyte.cxx:324:1: error:
‘store::{anonymous}::FileLockBytes::FileLockBytes(const
store::{anonymous}::FileHandle&)’ defined but not used
[-Werror=unused-function]
  324 | FileLockBytes::FileLockBytes (FileHandle const & rFile)
  | ^
cc1plus: all warnings being treated as errors




--
Sent from: 
http://document-foundation-mail-archive.969070.n3.nabble.com/Dev-f1639786.html
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Local LO build on Raspberry pi 4b doesn't launch

2021-02-19 Thread julien2412

Rene Engelhard wrote
> With gcc it just works (well, in 7.0.4 without your patches), maybe with
> warnings, but it starts and passes the tests...

Ok I 'll give it a try.


Rene Engelhard wrote
> ...
> And PLEASE don't write "Raspberry pi" here, one also doesn't write "HP
> ProBook" or "Acer whatever" if one means an amd64 laptop or whatever
> fancy stationary PC model when one means some amd64 machine. :)

I must recognize I'm a bit lost in Arm processor world.
You talked about arm64 armhf, armv6, armv7, naively I thought about arm 32
bits and arm 64 bits, I should read more about this arm.

So instead of making free advertisement, perhaps ARM Cortex-A72 would be
better? (or perhaps this time  it'll be considered as Cortex ad).

Finally I just discovered that Raspbian was based on Debian and 32 bits
only, the 64 bits version will be renamed RaspberryOS and not based on
Debian (what a pity). Also I discovered this page
https://wiki.debian.org/RaspberryPi quoting some issues.
I've been offered this card and thought hardware was more open source but it
seems it's not the case and Arm is less standardized than x86 (for example
to list devices).
Anyway, I'm now completely off topic I suppose so I'll stop here.




--
Sent from: 
http://document-foundation-mail-archive.969070.n3.nabble.com/Dev-f1639786.html
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

[ABANDONED] Re: Local LO build on Raspberry pi 4b doesn't launch

2021-02-19 Thread julien2412

sberg wrote
> ...
> I guess you'd need to actually debug into that callVirtualMethod.
> ...

Since I got no idea how bridge stuff works, let's abandon this thread then.



--
Sent from: 
http://document-foundation-mail-archive.969070.n3.nabble.com/Dev-f1639786.html
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Local LO build on Raspberry pi 4b doesn't launch

2021-02-18 Thread julien2412

Thank you again Stephan for your feedback.

Is there anything I could test to provide more info?
I mean if there's some patch to add logs or anything, I can apply it and
provide the result.

Should I submit a bugtracker or Raspberry is too specific so it wouldn't
worth it?



--
Sent from: 
http://document-foundation-mail-archive.969070.n3.nabble.com/Dev-f1639786.html
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Local LO build on Raspberry pi 4b doesn't launch

2021-02-17 Thread julien2412

Another bt this time without Python (with gtk3 rendering so all the
accessibility stuff), I'll try with gen rendering.
bt2.txt

  



--
Sent from: 
http://document-foundation-mail-archive.969070.n3.nabble.com/Dev-f1639786.html
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Local LO build on Raspberry pi 4b doesn't launch

2021-02-17 Thread julien2412

sberg wrote
> Looks like there's some issue with running the Python interpreter 
> in-process.  And you apparently have some extension using old-style, 
> active registration of a Python component, which triggers the issue when 
> starting soffice.  If you do not want to debug the issue with the Python 
> interpreter, I would suggest you make sure you do not have any 
> extensions involving Python (likely one of your --enable-ext-* 
> configuration options).

Thank you for your feedback.
So I disabled these in my autogen.input:
#--enable-ext-nlpsolver
#--enable-ext-ct2n
#--enable-ext-numbertext
#--enable-ext-wiki-publisher
and startcenter launches.

I tried launching Writer but got another bt:
bt.txt

  

Do you think about another item in my autogen.input that I should disable
because of an old-style 
active registration of a Python component?

Julien




--
Sent from: 
http://document-foundation-mail-archive.969070.n3.nabble.com/Dev-f1639786.html
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Failing LO build with Raspberry pi4 (-Werror,-Wformat in idl)

2021-02-13 Thread julien2412

I submitted this patch on gerrit:
https://gerrit.libreoffice.org/c/core/+/110844



--
Sent from: 
http://document-foundation-mail-archive.969070.n3.nabble.com/Dev-f1639786.html
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

About putting explicit bounty link in bugtrackers

2021-01-30 Thread julien2412

Hello,

Reading a French page
https://linuxfr.org/users/qdm/journaux/programmes-de-bug-bounty-dans-les-projets-libres-en-general-et-libreoffice-en-particulier
about bounties in FLOSS and LO specifically, I wonder if it could be
interesting to add a bounty link in bugtracker.

I mean, we all know we got a pb of human resources to fix bugs so we need to
be able to motivate people/newcomers.
Of course bounties is not a new idea but perhaps it would help to increase
its visibility by putting an explicit link (and perhaps also a field
displaying total amount so in a search it could be sorted with it?)
Now I must recognize I don't know websites/softs about bounties/crowfunding
and don't know too if Bugzilla can be easily customisable, it's just an
idea.

Julien



--
Sent from: 
http://document-foundation-mail-archive.969070.n3.nabble.com/Dev-f1639786.html
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: About Jenkins/TBs synchro

2021-01-18 Thread julien2412

Miklos Vajna-6 wrote
> Hi Julien,
> 
> On Sat, Jan 16, 2021 at 03:32:35AM -0700, julien2412 

> serval2412@

>  wrote:
>> These generate a waste of time (even with resume build/rebase action,
>> some
>> commits may be stuck waiting in gerrit).
> 
> My understanding is that his case was about breaking the Windows 64bit
> build, while pre-submit Jenkins "only" tests 32bit Windows and 3 other
> configs.
> 
> Do you have a proposal how to improve the coverage here, without
> increasing the time needed for a Jenkins run? E.g. you could drop 32bit
> Windows, but that is the only 32bit config, so perhaps you loose more
> than what you gain.
> ...

IMHO, we should add a Windows64 machine on Jenkins part (triggered in the
same time as Win32 to not lose time). Of course, it means more infra so if
we had to choose between Win32 and Win64, IMHO Win64 would be more relevant.

Julien



--
Sent from: 
http://document-foundation-mail-archive.969070.n3.nabble.com/Dev-f1639786.html
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

[ABANDONED] Re: About upgrading towards Postgresql 13.1

2021-01-17 Thread julien2412

I began with https://gerrit.libreoffice.org/c/core/+/109456 but it even fails
on Linux with:
ar crs libpgport.a fls.o getpeereid.o strlcat.o strlcpy.o pg_crc32c_sse42.o
pg_crc32c_sb8.o pg_crc32c_sse42_choose.o chklocale.o erand48.o
inet_net_ntop.o noblock.o path.o pg_bitutils.o pg_strong_random.o
pgcheckdir.o pgmkdirp.o pgsleep.o pgstrcasecmp.o pgstrsignal.o pqsignal.o
qsort.o qsort_arg.o quotes.o snprintf.o sprompt.o strerror.o tar.o thread.o
clang -Wall -Wmissing-prototypes -Wpointer-arith
-Wdeclaration-after-statement -Werror=vla -Wendif-labels
-Wmissing-format-attribute -Wformat-security -fno-strict-aliasing -fwrapv
-Wno-unused-command-line-argument -O2 -fPIC -I../../src/port -DFRONTEND
-I../../src/include
-I/home/julien/lo/libreoffice/workdir/UnpackedTarball/icu/source/i18n
-I/home/julien/lo/libreoffice/workdir/UnpackedTarball/icu/source/common
-I/home/julien/lo/libreoffice/workdir/UnpackedTarball/openssl/include
-I/home/julien/lo/libreoffice/workdir/UnpackedTarball/openldap/include
-D_GNU_SOURCE  -c path.c -o path_shlib.o
rm -f libpgport_shlib.a
ar crs libpgport_shlib.a fls_shlib.o getpeereid_shlib.o strlcat_shlib.o
strlcpy_shlib.o pg_crc32c_sse42_shlib.o pg_crc32c_sb8_shlib.o
pg_crc32c_sse42_choose_shlib.o chklocale_shlib.o erand48_shlib.o
inet_net_ntop_shlib.o noblock_shlib.o path_shlib.o pg_bitutils_shlib.o
pg_strong_random_shlib.o pgcheckdir_shlib.o pgmkdirp_shlib.o pgsleep_shlib.o
pgstrcasecmp_shlib.o pgstrsignal_shlib.o pqsignal_shlib.o qsort_shlib.o
qsort_arg_shlib.o quotes_shlib.o snprintf_shlib.o sprompt_shlib.o
strerror_shlib.o tar_shlib.o thread_shlib.o
clang -Wall -Wmissing-prototypes -Wpointer-arith
-Wdeclaration-after-statement -Werror=vla -Wendif-labels
-Wmissing-format-attribute -Wformat-security -fno-strict-aliasing -fwrapv
-Wno-unused-command-line-argument -O2  -I../../src/port  -I../../src/include
-I/home/julien/lo/libreoffice/workdir/UnpackedTarball/icu/source/i18n
-I/home/julien/lo/libreoffice/workdir/UnpackedTarball/icu/source/common
-I/home/julien/lo/libreoffice/workdir/UnpackedTarball/openssl/include
-I/home/julien/lo/libreoffice/workdir/UnpackedTarball/openldap/include
-D_GNU_SOURCE  -c chklocale.c -o chklocale_srv.o
In file included from chklocale.c:17:
In file included from ../../src/include/postgres.h:47:
../../src/include/utils/elog.h:71:10: fatal error: 'utils/errcodes.h' file
not found
#include "utils/errcodes.h"
 ^~
1 error generated.

after comparing 9 and 13 versions to try to understand why it failed on
Linux, but didn't find.

If the very first pb is so difficult and considering there were still Mac
and Win builds to fix, thought it would be useless to keep on, I gave up.

Remark: I could build Postgresql source from
git.postgresql.org/git/postgresql.git just with usual configure and make. So
no libs lacking here.

(just wonder why it doesn't build out-of-the box or minimum/generic
instructions)



--
Sent from: 
http://document-foundation-mail-archive.969070.n3.nabble.com/Dev-f1639786.html
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: About upgrading towards Postgresql 13.1

Jan-Marek Glogowski wrote
> Am 16.01.21 um 10:28 schrieb julien2412:
>> Taking a look at
>> https://bugs.documentfoundation.org/show_bug.cgi?id=139598,
>> could someone retrieve postgresql-13.1.tar.bz2 from
>> https://www.postgresql.org/ftp/source/v13.1/ and make it available on
>> https://dev-www.libreoffice.org/src/ ?
> 
> Done
> ...

Thank you for the quick feedback!

I submitted https://gerrit.libreoffice.org/c/core/+/109456 but it's a WIP it
doesn't even build on Linux.
I removed all patches because I think it's better to start from scratch.

Julien



--
Sent from: 
http://document-foundation-mail-archive.969070.n3.nabble.com/Dev-f1639786.html
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

About Jenkins/TBs synchro

Hello,

As you already know, there are often some Jenkins failures for reason
unrelated to the commit.
These generate a waste of time (even with resume build/rebase action, some
commits may be stuck waiting in gerrit).

In addition, we see that it happens some commits that were ok for Jenkins
make some TBs fail.
Eg: https://gerrit.libreoffice.org/c/core/+/107435 which was ok for Jenkins
make TB Jenkins_Win64_Dbg fail with:
4789  NEXT   
C:/cygwin/home/tdf/lode/jenkins/workspace/lo_tb_master_win64_dbg/cui/source/dialogs/FontFeaturesDialog.cxx(79):
error C2672: ´std::min´: no matching overloaded function found
4790  NEXT   
C:/cygwin/home/tdf/lode/jenkins/workspace/lo_tb_master_win64_dbg/cui/source/dialogs/FontFeaturesDialog.cxx(81):
error C2780: ´_Ty std::min(std::initializer_list<_Elem>)´: expects 1
arguments - 2 provided
4791 
C:\PROGRA~2\MIB055~1\2019\COMMUN~1\VC\Tools\MSVC\1425~1.286\Include\algorithm(4551):
note: see declaration of ´std::min´
4792  NEXT   
C:/cygwin/home/tdf/lode/jenkins/workspace/lo_tb_master_win64_dbg/cui/source/dialogs/FontFeaturesDialog.cxx(81):
error C2782: ´const _Ty ::min(const _Ty &,const _Ty &)
noexcept()´: template parameter ´_Ty´ is ambiguous
4793 
C:\PROGRA~2\MIB055~1\2019\COMMUN~1\VC\Tools\MSVC\1425~1.286\Include\algorithm(4538):
note: see declaration of ´std::min´
4794 
C:/cygwin/home/tdf/lode/jenkins/workspace/lo_tb_master_win64_dbg/cui/source/dialogs/FontFeaturesDialog.cxx(81):
note: could be ´long´
4795 
C:/cygwin/home/tdf/lode/jenkins/workspace/lo_tb_master_win64_dbg/cui/source/dialogs/FontFeaturesDialog.cxx(81):
note: or   ´_Ty´
4796  with
4797  [
4798  _Ty=tools::Long
4799  ]
4800  NEXTC:/cygwin/home

Considering https://gerrit.libreoffice.org/q/status:abandoned, I see
there've been recent actions to try tackle Jenkins pbs but are there planned
actions for TBs too?

Julien



--
Sent from: 
http://document-foundation-mail-archive.969070.n3.nabble.com/Dev-f1639786.html
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

[SOLVED] Re: Building LO on Raspberry pi 4b, error: unknown attribute 'externally_visible' on jni part

Just for the record, after commit
https://cgit.freedesktop.org/libreoffice/core/commit/?id=ebb0ac4c922b51191979ca376f7c7d7581ace62e
done with Stephan's help, the build on Raspberry pi 4b succeeded with quoted
autogen.input.

(see https://cgit.freedesktop.org/libreoffice/core/log/?qt=grep=raspberry
for the list of related patches).



--
Sent from: 
http://document-foundation-mail-archive.969070.n3.nabble.com/Dev-f1639786.html
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

About upgrading towards Postgresql 13.1

Hello,

Taking a look at https://bugs.documentfoundation.org/show_bug.cgi?id=139598,
could someone retrieve postgresql-13.1.tar.bz2 from
https://www.postgresql.org/ftp/source/v13.1/ and make it available on
https://dev-www.libreoffice.org/src/ ?
I don't pretend being able to make it on my own (considering all the pbs
there were for the Firebird 3.0.7 upgrade) but perhaps with some help we may
do this big leap (9.2.24 -> 13.1)

Julien



--
Sent from: 
http://document-foundation-mail-archive.969070.n3.nabble.com/Dev-f1639786.html
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Getting started

2021-01-14 Thread julien2412

Hello,

Did you take a look at
https://wiki.documentfoundation.org/Development/GetInvolved ?

Most of LO code (95%?) is C++.
About Java, the goal is to try to reduce dependency on Java.
For QA tests, we try to migrate Java tests towards Python or even better
towards C++.

Julien



--
Sent from: 
http://document-foundation-mail-archive.969070.n3.nabble.com/Dev-f1639786.html
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

[SOLVED] Re: Warnings about Boost (warning: The practice of declaring the Bind placeholders (_1, _2, ...) in the global namespace is deprecated)

2021-01-14 Thread julien2412

Thank you Stephan!



--
Sent from: 
http://document-foundation-mail-archive.969070.n3.nabble.com/Dev-f1639786.html
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Question regarding LO 7.1 release notes: Did any previously "experimental features" mature?

2021-01-11 Thread julien2412

Hello,

About Firebird, there's been a migration from 3.0.0 to 3.0.7 could be done
thanks to the great help of Jan-Marek and Stephan and some bugfixes but IMHO
it'll stay experimental a long time since there are too few bugfixes about
it considering the number of related opened bugs.

Julien



--
Sent from: 
http://document-foundation-mail-archive.969070.n3.nabble.com/Dev-f1639786.html
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Building LO on Raspberry pi 4b, error: unknown attribute 'externally_visible' on jni part

2021-01-10 Thread julien2412

I pushed some commits to fix some errors, see
https://cgit.freedesktop.org/libreoffice/core/log/?qt=grep=raspberry.
I don't know if they're the right fixes but at least, the build could go on.

Now I'm struggling a bit with these errors:
In file included from /home/pi/lo/libreoffice/vcl/skia/SkiaHelper.cxx:34:
In file included from /home/pi/lo/libreoffice/vcl/inc/skia/utils.hxx:28:
In file included from
/home/pi/lo/libreoffice/workdir/UnpackedTarball/skia/include/core/SkRegion.h:11:
In file included from
/home/pi/lo/libreoffice/workdir/UnpackedTarball/skia/include/core/SkRect.h:11:
In file included from
/home/pi/lo/libreoffice/workdir/UnpackedTarball/skia/include/core/SkPoint.h:11:
In file included from
/home/pi/lo/libreoffice/workdir/UnpackedTarball/skia/include/core/SkMath.h:11:
/home/pi/lo/libreoffice/workdir/UnpackedTarball/skia/include/core/SkTypes.h:371:5:
error: 'SK_CPU_SSE_LEVEL' is not defined, evaluates to 0 [-Werror,-Wundef]
#if SK_CPU_SSE_LEVEL >= SK_CPU_SSE_LEVEL_SSE1
^
In file included from /home/pi/lo/libreoffice/vcl/skia/SkiaHelper.cxx:34:
In file included from /home/pi/lo/libreoffice/vcl/inc/skia/utils.hxx:28:
In file included from
/home/pi/lo/libreoffice/workdir/UnpackedTarball/skia/include/core/SkRegion.h:11:
In file included from
/home/pi/lo/libreoffice/workdir/UnpackedTarball/skia/include/core/SkRect.h:11:
In file included from
/home/pi/lo/libreoffice/workdir/UnpackedTarball/skia/include/core/SkPoint.h:12:
In file included from
/home/pi/lo/libreoffice/workdir/UnpackedTarball/skia/include/core/SkScalar.h:11:
/home/pi/lo/libreoffice/workdir/UnpackedTarball/skia/include/private/SkFloatingPoint.h:21:5:
error: 'SK_CPU_SSE_LEVEL' is not defined, evaluates to 0 [-Werror,-Wundef]
#if SK_CPU_SSE_LEVEL >= SK_CPU_SSE_LEVEL_SSE1
^
/home/pi/lo/libreoffice/workdir/UnpackedTarball/skia/include/private/SkFloatingPoint.h:203:5:
error: 'SK_CPU_SSE_LEVEL' is not defined, evaluates to 0 [-Werror,-Wundef]
#if SK_CPU_SSE_LEVEL >= SK_CPU_SSE_LEVEL_SSE1
^
In file included from /home/pi/lo/libreoffice/vcl/skia/salbmp.cxx:20:
In file included from /home/pi/lo/libreoffice/vcl/inc/skia/salbmp.hxx:25:
In file included from
/home/pi/lo/libreoffice/workdir/UnpackedTarball/skia/include/core/SkImage.h:11:
In file included from
/home/pi/lo/libreoffice/workdir/UnpackedTarball/skia/include/core/SkFilterQuality.h:11:
/home/pi/lo/libreoffice/workdir/UnpackedTarball/skia/include/core/SkTypes.h:371:5:
error: 'SK_CPU_SSE_LEVEL' is not defined, evaluates to 0 [-Werror,-Wundef]
#if SK_CPU_SSE_LEVEL >= SK_CPU_SSE_LEVEL_SSE1
^
In file included from /home/pi/lo/libreoffice/vcl/skia/salbmp.cxx:20:
In file included from /home/pi/lo/libreoffice/vcl/inc/skia/salbmp.hxx:25:
In file included from
/home/pi/lo/libreoffice/workdir/UnpackedTarball/skia/include/core/SkImage.h:12:
In file included from
/home/pi/lo/libreoffice/workdir/UnpackedTarball/skia/include/core/SkImageEncoder.h:11:
In file included from
/home/pi/lo/libreoffice/workdir/UnpackedTarball/skia/include/core/SkBitmap.h:11:
In file included from
/home/pi/lo/libreoffice/workdir/UnpackedTarball/skia/include/core/SkColor.h:11:
In file included from
/home/pi/lo/libreoffice/workdir/UnpackedTarball/skia/include/core/SkImageInfo.h:11:
In file included from
/home/pi/lo/libreoffice/workdir/UnpackedTarball/skia/include/core/SkColorSpace.h:12:
In file included from
/home/pi/lo/libreoffice/workdir/UnpackedTarball/skia/include/private/SkFixed.h:11:
In file included from
/home/pi/lo/libreoffice/workdir/UnpackedTarball/skia/include/core/SkScalar.h:11:
/home/pi/lo/libreoffice/workdir/UnpackedTarball/skia/include/private/SkFloatingPoint.h:21:5:
error: 'SK_CPU_SSE_LEVEL' is not defined, evaluates to 0 [-Werror,-Wundef]
#if SK_CPU_SSE_LEVEL >= SK_CPU_SSE_LEVEL_SSE1
^
/home/pi/lo/libreoffice/workdir/UnpackedTarball/skia/include/private/SkFloatingPoint.h:203:5:
error: 'SK_CPU_SSE_LEVEL' is not defined, evaluates to 0 [-Werror,-Wundef]
#if SK_CPU_SSE_LEVEL >= SK_CPU_SSE_LEVEL_SSE1
^
3 errors generated.

If someone knows has an idea to fix this...

BTW, if someone wants me to try some patches to see how it behave in
Raspberry pi 4, don't hesitate.
Of course, try to avoid patches which need an almost full rebuild, Arm
Cortex A72 with 4GB is not very fast :-)

Julien



--
Sent from: 
http://document-foundation-mail-archive.969070.n3.nabble.com/Dev-f1639786.html
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Warnings about Boost (warning: The practice of declaring the Bind placeholders (_1, _2, ...) in the global namespace is deprecated)

2021-01-07 Thread julien2412

Hello,

On pc Debian x86-64 with master sources updated today + make clean && make
(since Boost has been upgraded), I noticed these kinds of warnings:
[CXX] svx/source/fmcomp/fmgridif.cxx
In file included from
/home/julien/lo/libreoffice/svx/source/xoutdev/xattr.cxx:87:
In file included from
/home/julien/lo/libreoffice/external/boost/include/boost/property_tree/json_parser.hpp:30:
In file included from
/home/julien/lo/libreoffice/workdir/UnpackedTarball/boost/boost/property_tree/json_parser.hpp:16:
In file included from
/home/julien/lo/libreoffice/workdir/UnpackedTarball/boost/boost/property_tree/json_parser/detail/read.hpp:13:
In file included from
/home/julien/lo/libreoffice/workdir/UnpackedTarball/boost/boost/property_tree/json_parser/detail/parser.hpp:7:
In file included from
/home/julien/lo/libreoffice/external/boost/include/boost/bind.hpp:30:
/home/julien/lo/libreoffice/workdir/UnpackedTarball/boost/boost/bind.hpp:36:1:
warning: The practice of declaring the Bind placeholders (_1, _2, ...) in
the global namespace is deprecated. Please use  + using
namespace boost::placeholders, or define BOOST_BIND_GLOBAL_PLACEHOLDERS to
retain the current behavior. [-W#pragma-messages]
BOOST_PRAGMA_MESSAGE(
^
/home/julien/lo/libreoffice/workdir/UnpackedTarball/boost/boost/config/pragma_message.hpp:24:34:
note: expanded from macro 'BOOST_PRAGMA_MESSAGE'
# define BOOST_PRAGMA_MESSAGE(x) _Pragma(BOOST_STRINGIZE(message(x)))
 ^
:36:2: note: expanded from here
 message("The practice of declaring the Bind placeholders (_1, _2, ...) "
"in the global namespace is deprecated. Please use " "
+ using namespace boost::placeholders, " "or define
BOOST_BIND_GLOBAL_PLACEHOLDERS to retain the current behavior.")
 ^

Here's my autogen.input:
CC=clang
CXX=clang++
--enable-compiler-plugins
--enable-dbgutil
--enable-evolution2
--enable-qt5
--enable-kf5
--enable-gtk3-kde5
# pour tester build rpm format
--enable-skia=debug
--enable-ext-nlpsolver
--enable-ext-ct2n
--enable-ext-numbertext
--enable-ext-wiki-publisher
--enable-dbus
--enable-online-update
--enable-werror
--enable-dependency-tracking
--enable-python=fully-internal
--without-system-mariadb
--enable-bundle-mariadb
--enable-symbols
--enable-avahi
--enable-eot
--enable-odk
--with-lang=en-US fr pt pt-BR it de
#--with-lang=ALL
--with-myspell-dicts
#--with-help

Debian clang version 11.0.0-5+b1
GNU ld (GNU Binutils for Debian) 2.35.1

It doesn't prevent LO from building but thought it could be interesting to
pinpoint.

Julien



--
Sent from: 
http://document-foundation-mail-archive.969070.n3.nabble.com/Dev-f1639786.html
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Windows 10 prerequisite for 7.2.0? (so abandon Windows 7 and avoid Windows 8)

2021-01-03 Thread julien2412

Hello,

Taking a look at https://en.wikipedia.org/wiki/Windows_7, Windows 7
(released in 2009) is now only "eligible for the Extended Security Updates
service. This service is available via OEMs, in yearly installments.
Security updates are available for the operating system until at most
January 10, 2023 only for Professional and Enterprise volume licensed
editions"

What about asking Windows 8 or rather Windows 10 as prerequisite for future
LO 7.2.0 Windows version?

(benefit: not wasting time on an obsolete system if not in dev part in QA
part for example)

Julien



--
Sent from: 
http://document-foundation-mail-archive.969070.n3.nabble.com/Dev-f1639786.html
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Building LO on Raspberry pi 4b, error: unknown attribute 'externally_visible' on jni part

2020-12-31 Thread julien2412

It seems "externally_visible" is a specific attribute of gcc (so not known by
clang).
See
https://gcc.gnu.org/onlinedocs/gcc-10.2.0/gcc/Common-Function-Attributes.html#Common-Function-Attributes
Reading the link, it seems we can ignore this error since it's only useful
if we use "-fwhole-program" and "git grep" in LO code shows it's not the
case.

So this patch removes the error:
diff --git a/bean/native/unix/com_sun_star_comp_beans_LocalOfficeWindow.c
b/bean/native/unix/com_sun_star_comp_beans_LocalOfficeWindow.c
index 069bb1ee050e..95b1434dd9c1 100644
--- a/bean/native/unix/com_sun_star_comp_beans_LocalOfficeWindow.c
+++ b/bean/native/unix/com_sun_star_comp_beans_LocalOfficeWindow.c
@@ -23,7 +23,17 @@
 #include 
 #include 
 
+// to deal with gcc specific attribute "externally_visible" used in
+// /usr/lib/jvm/java-11-openjdk-armhf/include/linux/jni_md.h:35
+// via /usr/lib/jvm/java-11-openjdk-armhf/include/jni.h
+#if defined __clang__
+#pragma clang diagnostic push
+#pragma clang diagnostic ignored "-Wunknown-attributes"
+#endif
 #include 
+#if defined __clang__
+#pragma clang diagnostic pop
+#endif

but "jni.h" is used in about 40 files (if we remove comments with jni.h or
odk examples).

I suppose a better solution exists than copy pasting this  workaround 40
times or perhaps should I avoid clang here and use gcc?

Julien



--
Sent from: 
http://document-foundation-mail-archive.969070.n3.nabble.com/Dev-f1639786.html
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Jenkins pb?

2020-12-31 Thread julien2412

Ilmari Lauhakangas wrote
> On 31.12.2020 11.19, julien2412 wrote:
> It was just discussed on #tdf-infra and is being worked on. Apparently 
> some ccache-related issue.

Thank you for the quick feedback.

I hope other random pbs will be taken into account, eg:
- Windows Jenkins which stops, see
https://ci.libreoffice.org/job/gerrit_windows/84600/console
- Mac Jenkins which fails for something obviously not related to the patch
(see https://ci.libreoffice.org/job/gerrit_mac/80144/console).

I don't count anymore the number of times I use "Resume" in jenkins for some
straightforward patches (I try to use "Rebase" on gerrit only if I see that
a recent commit may help or if jenkins seems stuck).

Julien




--
Sent from: 
http://document-foundation-mail-archive.969070.n3.nabble.com/Dev-f1639786.html
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Jenkins pb?

2020-12-31 Thread julien2412

Hello,

It seems there are more and more failing Jenkins not related to the tested
patches.
eg for https://ci.libreoffice.org/job/gerrit_master/74633/ with
https://ci.libreoffice.org/job/gerrit_linux_clang_dbgutil/76775/console

Started by upstream project "gerrit_master" build number 74633
originally caused by:
 Triggered by Gerrit: https://gerrit.libreoffice.org/c/core/+/108501
Running as SYSTEM
[EnvInject] - Loading node environment variables.
Building remotely on tb85 (android_aarch64 android_x86 android_x86_64 Linux
Gerrit android_arm linux_clang_dbgutil_64) in workspace
/home/tdf/lode/jenkins/workspace/lo_gerrit/Config/linux_clang_dbgutil_64
The recommended git tool is: NONE
No credentials specified
 > git rev-parse --is-inside-work-tree # timeout=10
Fetching changes from the remote Git repository
 > git config remote.origin.url https://git.libreoffice.org/core #
timeout=10
ERROR: Error fetching remote repo 'origin'
hudson.plugins.git.GitException: Failed to fetch from
https://git.libreoffice.org/core
at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:1001)
at hudson.plugins.git.GitSCM.retrieveChanges(GitSCM.java:1242)
at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1302)
at hudson.scm.SCM.checkout(SCM.java:505)
at hudson.model.AbstractProject.checkout(AbstractProject.java:1204)
at
hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:636)
at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86)
at
hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:508)
at hudson.model.Run.execute(Run.java:1907)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
at hudson.model.ResourceController.execute(ResourceController.java:97)
at hudson.model.Executor.run(Executor.java:429)
Caused by: hudson.plugins.git.GitException: Command "git config
remote.origin.url https://git.libreoffice.org/core; returned status code 4:
stdout: 
stderr: error: failed to write new configuration file
/home/tdf/lode/jenkins/workspace/lo_gerrit/Config/linux_clang_dbgutil_64/.git/config.lock

at
org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:2450)
at
org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:2380)
at
org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:2376)

Is it just a matter of time? should the Jenkins machines be restarted? is
there some hardware pb?

Julien



--
Sent from: 
http://document-foundation-mail-archive.969070.n3.nabble.com/Dev-f1639786.html
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Building LO on Raspberry pi 4b, error: unknown attribute 'externally_visible' on jni part

2020-12-30 Thread julien2412

Hello,

I'm giving a try at building LO on Raspberry pi 4b.
Here's the autogen.input I use:
CC=clang
CXX=clang++
--enable-compiler-plugins
--enable-ext-nlpsolver
--enable-ext-ct2n
--enable-ext-numbertext
--enable-ext-wiki-publisher
--enable-dbus
--enable-online-update
--enable-werror
--enable-dependency-tracking
--enable-python=fully-internal
--without-system-mariadb
--enable-bundle-mariadb
--enable-symbols
--enable-avahi
--enable-eot
--enable-odk
--with-lang=en-US fr
--with-myspell-dicts

Here's the first (I expect others) errors I get:
In file included from
/home/pi/lo/libreoffice/bean/native/unix/com_sun_star_comp_beans_LocalOfficeWindow.c:26:
/usr/lib/jvm/java-11-openjdk-armhf/include/jni.h:1945:1: error: unknown
attribute 'externally_visible' ignored [-Werror,-Wunknown-attributes]
_JNI_IMPORT_OR_EXPORT_ jint JNICALL
^
/usr/lib/jvm/java-11-openjdk-armhf/include/jni.h:1943:32: note: expanded
from macro '_JNI_IMPORT_OR_EXPORT_'
#define _JNI_IMPORT_OR_EXPORT_ JNIIMPORT
   ^
/usr/lib/jvm/java-11-openjdk-armhf/include/linux/jni_md.h:35:42: note:
expanded from macro 'JNIIMPORT'
#define JNIIMPORT
__attribute__((externally_visible,visibility("default")))
 ^
In file included from
/home/pi/lo/libreoffice/bean/native/unix/com_sun_star_comp_beans_LocalOfficeWindow.c:26:
/usr/lib/jvm/java-11-openjdk-armhf/include/jni.h:1948:1: error: unknown
attribute 'externally_visible' ignored [-Werror,-Wunknown-attributes]
_JNI_IMPORT_OR_EXPORT_ jint JNICALL
^
/usr/lib/jvm/java-11-openjdk-armhf/include/jni.h:1943:32: note: expanded
from macro '_JNI_IMPORT_OR_EXPORT_'
#define _JNI_IMPORT_OR_EXPORT_ JNIIMPORT
   ^
/usr/lib/jvm/java-11-openjdk-armhf/include/linux/jni_md.h:35:42: note:
expanded from macro 'JNIIMPORT'
#define JNIIMPORT
__attribute__((externally_visible,visibility("default")))
 ^
In file included from
/home/pi/lo/libreoffice/bean/native/unix/com_sun_star_comp_beans_LocalOfficeWindow.c:26:
/usr/lib/jvm/java-11-openjdk-armhf/include/jni.h:1951:1: error: unknown
attribute 'externally_visible' ignored [-Werror,-Wunknown-attributes]
_JNI_IMPORT_OR_EXPORT_ jint JNICALL
^
/usr/lib/jvm/java-11-openjdk-armhf/include/jni.h:1943:32: note: expanded
from macro '_JNI_IMPORT_OR_EXPORT_'
#define _JNI_IMPORT_OR_EXPORT_ JNIIMPORT
   ^
/usr/lib/jvm/java-11-openjdk-armhf/include/linux/jni_md.h:35:42: note:
expanded from macro 'JNIIMPORT'
#define JNIIMPORT
__attribute__((externally_visible,visibility("default")))
 ^
In file included from
/home/pi/lo/libreoffice/bean/native/unix/com_sun_star_comp_beans_LocalOfficeWindow.c:26:
/usr/lib/jvm/java-11-openjdk-armhf/include/jni.h:1955:1: error: unknown
attribute 'externally_visible' ignored [-Werror,-Wunknown-attributes]
JNIEXPORT jint JNICALL
^
/usr/lib/jvm/java-11-openjdk-armhf/include/linux/jni_md.h:34:42: note:
expanded from macro 'JNIEXPORT'
#define JNIEXPORT
__attribute__((externally_visible,visibility("default")))
 ^
In file included from
/home/pi/lo/libreoffice/bean/native/unix/com_sun_star_comp_beans_LocalOfficeWindow.c:26:
/usr/lib/jvm/java-11-openjdk-armhf/include/jni.h:1958:1: error: unknown
attribute 'externally_visible' ignored [-Werror,-Wunknown-attributes]
JNIEXPORT void JNICALL
^
/usr/lib/jvm/java-11-openjdk-armhf/include/linux/jni_md.h:34:42: note:
expanded from macro 'JNIEXPORT'
#define JNIEXPORT
__attribute__((externally_visible,visibility("default")))
 ^
In file included from
/home/pi/lo/libreoffice/bean/native/unix/com_sun_star_comp_beans_LocalOfficeWindow.c:28:
In file included from
/usr/lib/jvm/java-11-openjdk-armhf/include/linux/jawt_md.h:31:
/usr/lib/jvm/java-11-openjdk-armhf/include/jawt.h:337:1: error: unknown
attribute 'externally_visible' ignored [-Werror,-Wunknown-attributes]
_JNI_IMPORT_OR_EXPORT_
^
/usr/lib/jvm/java-11-openjdk-armhf/include/jni.h:1943:32: note: expanded
from macro '_JNI_IMPORT_OR_EXPORT_'
#define _JNI_IMPORT_OR_EXPORT_ JNIIMPORT
   ^
/usr/lib/jvm/java-11-openjdk-armhf/include/linux/jni_md.h:35:42: note:
expanded from macro 'JNIIMPORT'
#define JNIIMPORT
__attribute__((externally_visible,visibility("default")))
 ^
6 errors generated.
make[1]: *** [/home/pi/lo/libreoffice/solenv/gbuild/LinkTarget.mk:238 :
/home/pi/lo/libreoffice/workdir/CObject/bean/native/unix/com_sun_star_comp_beans_LocalOfficeWindow.o]
Erreur 1


Is it possible to fix this or can we just workaround this by forcing clang
to ignore these?

Julien



--
Sent from: 
http://document-foundation-mail-archive.969070.n3.nabble.com/Dev-f1639786.html
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org

Re: Dropping X11 VCL backend

2020-12-29 Thread julien2412

Ilmari Lauhakangas wrote
> On 29.12.2020 11.11, julien2412 wrote:
>> ...
> kf5 comes from KDE Frameworks 5.

Thank you, I'll try to remember this one.

Ilmari Lauhakangas wrote
> The extra libs to install are (on Debian & Ubuntu):
> 
> qtbase5-dev libkf5coreaddons-dev libkf5i18n-dev libkf5config-dev 
> libkf5windowsystem-dev libkf5kio-dev

Yep I had installed them, just meant it needed extra libs.
Still, gen rendering is nearer to Windows rendering than kf5 too (at least
it seems too).

Ilmari Lauhakangas wrote
> Yeah, but if gen/x11 stops having a practical use, then it will merely 
> be an extra thing to test with its own quirks, causing constant 
> maintenance effort.

I understand but IMHO Skia support in LO is not enough mature (first commit
on master branch of LO is in 2019-11-27 so just 1 year whereas it's an
essential component) and above all, it needs at least one additional
maintainer (for me the main pb here) (see my response to Chris).

--
Sent from: 
http://document-foundation-mail-archive.969070.n3.nabble.com/Dev-f1639786.html
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Dropping X11 VCL backend

2020-12-29 Thread julien2412

Hello Ilmari,

I use gen rendering when trying to be nearer of a Windows config.
Indeed, I'm on pc Debian x86-64 with master sources and by default it uses
gtk3.
Badfully, gtk3 uses accessibility part which has been quite broken since
years (but I suppose no one will want to remove it). So sometimes, I got
some assertion or bug with gtk3 which prevents me to reproduce the real bug.
There's also kf5 rendering (corresponding to kde, I don't know why it's not
called "kde5") which doesn't use accessibility but need a lot of extra libs
to install (there are also all related Plasma and Wayland things that I
don't know enough so sometimes it's not easy to reproduce kde specific
bugs).

Finally gen rendering which "seem" (perhaps I'm wrong here) not to use extra
libs and in which some window dialogs are not modal (I don't know why) is a
good complement to test (even if I dislike UI above all open file window
dialog).

Julien



--
Sent from: 
http://document-foundation-mail-archive.969070.n3.nabble.com/Dev-f1639786.html
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Dropping X11 VCL backend

2020-12-29 Thread julien2412

Hello Chris,

Just my personal opinion of course but I think my message from 2020-04-25 is
still relevant (see
http://document-foundation-mail-archive.969070.n3.nabble.com/SKIA-on-Windows-Roadmap-ESC-agenda-item-tt4277989.html#a4278039),
I'll just quote myself:
"
1) if Luboš doesn't want or can't anymore fix the Skia bugs, whatever the
reasons, who will be able to fix these bugs?
Indeed, 95% of Skia patches are from Luboš. So for me it's a risk.
Ideally there should be someone not from Collabora, nothing against this
company but LO shouldn't rely exclusively from it for this very central
part.

2) Even if Luboš does a great job fixing Skia bugs, there are only 6 opened
now on about 50 bugs declared on tdf#129062 (Meta Skia).
However it seems only LO people declared Skia bugs therefore I expect far
more bugs when it'll be default in 7.0. So I think we should keep the
possibility to revert the default option for 7.0.1/7.0.2 just in case.
For those who would consider this as very hypothetical, just consider
Firebird experience.

3) Is there some documentation to facilitate newcomers or not LO newcomers
devs to work on this?
(I found nothing in https://wiki.documentfoundation.org) "

About 2) there are now 14 open bugs now.

I had put this kind of comments here:
https://bugs.documentfoundation.org/show_bug.cgi?id=132323 (Make SKIA
default. Move OpenGL and GDI rendering to Expert configuration)

I always support removing old things if they're broken, experimental, (eg: I
removed VLC support and tried to remove TB AB but stuck because public API)
but I'm against if they're still used and there's no ready replacement.
Also, as long as Luboš is the only person able to maintain support of Skia,
I think it's too risky.

Julien

--
Sent from:
http://document-foundation-mail-archive.969070.n3.nabble.com/Dev-f1639786.html
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

[SOLVED] Re: About vcl status in avmedia (keep or removed unmaintained code since 7 years)

2020-12-25 Thread julien2412

Pushed now.

Of course, if someone wants to work on it, don't hesitate to revert the
patch.



--
Sent from: 
http://document-foundation-mail-archive.969070.n3.nabble.com/Dev-f1639786.html
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: About vcl status in avmedia (keep or removed unmaintained code since 7 years)

2020-12-25 Thread julien2412

I submitted a patch here to remove vlc:
https://gerrit.libreoffice.org/c/core/+/108283



--
Sent from: 
http://document-foundation-mail-archive.969070.n3.nabble.com/Dev-f1639786.html
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

About vcl status in avmedia (keep or removed unmaintained code since 7 years)

2020-12-24 Thread julien2412

Hello,

On pc Debian x86-64 with master sources updated today, my local build fails
with:
/home/julien/lo/libreoffice/avmedia/source/vlc/vlcframegrabber.cxx:25:10:
fatal error: 'vcl/bitmapaccess.hxx' file not found
#include 
 ^~

It's due
https://cgit.freedesktop.org/libreoffice/core/commit/?id=17aea7c41c95186c03c173a8c6f26cd2ebce4c54
"
author  Chris Sherlock  2020-12-19 01:09:27 
+1100
committer   Tomaž Vajngerl2020-12-24 09:40:16 
+0100
commit  17aea7c41c95186c03c173a8c6f26cd2ebce4c54 (patch)
tree36c0743c40f3a85467247c585431682334ef3279
parent  d117d402853ee6c103142f0d0ccdb7cd4b8b8d05 (diff)
vcl: move access functions into appropriate bitmap access filesHEADmaster
Split class functions into BitmapInfoAccess.cxx, BitmapReadAccess.cxx
and BitmapWriteAccess.cxx

Split header files into BitmapInfoAccess.hxx and BitmapReadAccess.hxx"

but I suppose it'll be fixed soon.

I had this error and neither Jenkins nor TBs because I use "--enable-vlc" in
autogen.input.
Like other entries in autogen.input, I don't use vlc part, it's more to
detect build errors early.

However considering git history about vlc part (see
https://cgit.freedesktop.org/libreoffice/core/log/?qt=grep=vlc) it seems
there's no real patch since 2013 + it's been explicitely indicated as 
experimental since 2015 with
https://cgit.freedesktop.org/libreoffice/core/commit/?id=8f4044afa2426befb3f86dda21963576dbb19a9f
"avmedia: disable VLC unless in experimental model.
The code is really not in an ideal state, the key-frame generation is
horrible - involving playing the video for three seconds each time etc.
While the idea is great - the impl. and libvlc API use needs some love
from a VLC expert really."

VLC is indeed a great software but if the support of it in LO has been
unmaintained for so many years (IMHO 7 years is very long in IT domain),
should we still keep this or may we remove it?

Julien



--
Sent from: 
http://document-foundation-mail-archive.969070.n3.nabble.com/Dev-f1639786.html
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

[SOLVED] Re: 2 commits pushed on gerrit but not retrievable and not present in cgit.

2020-12-22 Thread julien2412

sberg wrote
> both of them are "Marking change merged without cherry-picking to 
> branch, as the resulting commit would be empty."  i.e., apparently some 
> other commit(s) meanwhile made the exact same changes?

Thank you for the feedback Stephan!
Indeed for https://gerrit.libreoffice.org/c/core/+/108120, it's empty.
For the other, it's not empty but saw also this message, weird...
At least nothing lost :-)



--
Sent from: 
http://document-foundation-mail-archive.969070.n3.nabble.com/Dev-f1639786.html
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

2 commits pushed on gerrit but not retrievable and not present in cgit.

2020-12-22 Thread julien2412

Hello,

On branch master, I pushed these commits:
- https://gerrit.libreoffice.org/c/core/+/106303
tdf#124176: Use pragma once instead of include guards
from çağatay kılınç
- https://gerrit.libreoffice.org/c/core/+/108120
Removed executable permission on file docx
from Andrea Gelmini

I don't see them on https://cgit.freedesktop.org/libreoffice/core/log/
and I didn't retrieve them on my local repo.
Here's my git/.config:
[core]
repositoryformatversion = 0
filemode = true
bare = false
logallrefupdates = true
[remote "origin"]
url = ssh://serval2...@gerrit.libreoffice.org:29418/core.git
#url = ssh://logerrit/core
fetch = +refs/heads/*:refs/remotes/origin/*
pushurl = ssh://logerrit/core
[branch "master"]
remote = origin
merge = refs/heads/master
[submodule "translations"]
active = true
#url = ssh://serval2...@gerrit.libreoffice.org:29418/translations
#url = git://gerrit.libreoffice.org/translations
url = https://gerrit.libreoffice.org/translations
[submodule "dictionaries"]
active = true
url = ssh://serval2...@gerrit.libreoffice.org:29418/dictionaries
#url = https://gerrit.libreoffice.org/dictionaries
[submodule "helpcontent2"]
active = true
url = ssh://serval2...@gerrit.libreoffice.org:29418/help
#url = https://gerrit.libreoffice.org/help
[protocol]
version = 2

Any thoughts? Did I miss something obvious?

Julien




--
Sent from: 
http://document-foundation-mail-archive.969070.n3.nabble.com/Dev-f1639786.html
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: About preparing migration towards gtk4

2020-12-19 Thread julien2412

Dante Doménech wrote
> Most linux distributions release versions once a year or two years.
> I wouldn't expect it to have support until a couple of years.
> So isn't it a bit early to implement support? I mean, nothing will be
> compatible with it.

That's why for the moment, only preparation may be done for the moment.
This action allows to stay gtk3 compatible and to begin the work needed for
gtk4 migration.
About gtk4 migration itself, I suppose there may be a specific subdir in
core/vcl/unx since there are already:
- generic
- gtk3
- gtk3_kde5
- kf5
- x11




--
Sent from: 
http://document-foundation-mail-archive.969070.n3.nabble.com/Dev-f1639786.html
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: About tdf#138715 and future of Thunderbird address book support

2020-12-19 Thread julien2412

I submitted https://gerrit.libreoffice.org/c/core/+/108017 for master
sources.

If Jenkins is ok and nobody complains, I'll push this and will update
https://wiki.documentfoundation.org/ReleaseNotes/7.2.

If the patch is pushed, I'll cherry-pick the patch on 7.1 branch. Indeed,
I'd like to avoid people to declare bugs about it for the next 6 months. Of
course, I know I can't decide all my myself when I cherry-pick, so don't
hesitate to comment.

Of course, helpcontent should be updated about Thunderbird AB. I'll take a
look but think I may need some help.

I had already indicated in
http://document-foundation-mail-archive.969070.n3.nabble.com/ESC-meeting-agenda-2020-12-17-16-00-Berlin-time-tt4292917.html
but I prefer repeating myself in this thread:
I saw that there was too the wrong named "Firefox address source" in Writer
wizard Address Data Source.
I'd like to remove this too since Firefox is a browser not a mailer. Of
course, perhaps it corresponds to "Mozilla Suite" or now "Seamonkey" since
they include a mailer module.
Now I'm not sure/don't know if these are very used and so if it worths it to
keep on maintaining this part.
I mean, it seems more and more people use webmail of their provider or
applications from their smartphone.

Julien



--
Sent from: 
http://document-foundation-mail-archive.969070.n3.nabble.com/Dev-f1639786.html
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: ESC meeting agenda: 2020-12-17 16:00 Berlin time

2020-12-18 Thread julien2412

julien2412 wrote
> Miklos Vajna-6 wrote
> ...
> Also there's the wrong named "Firebird" Address Data Source in Writer
> wizards, should we remove this (or rename it if it works with Mozilla
> Suite/Seamonkey but does it worth it?), knowing that the only remaining
> entry would be "Other" (not very UI friendly...)?
> .

Argh, I meant the "wrong named "Firefox" Address Data source". (words were
too closed for me :-) )



--
Sent from: 
http://document-foundation-mail-archive.969070.n3.nabble.com/Dev-f1639786.html
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

About preparing migration towards gtk4

2020-12-18 Thread julien2412

Hello,

Gtk4 has been released 2 days ago, I know that migration from a version to
another version is not a 1 month work, but thought it could be interesting
and it can't hurt the current state of LO to begin to prepare it by
following:
https://developer.gnome.org/gtk4/4.0/gtk-migrating-3-to-4.html#id-1.7.4.3.
I don't pretend I'd be able to propose some patches because I know nothing
about gtk but if I find some low hanging fruits, is it ok and/or does it
worth it to submit some?

Any thoughts?

Julien




--
Sent from: 
http://document-foundation-mail-archive.969070.n3.nabble.com/Dev-f1639786.html
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: ESC meeting agenda: 2020-12-17 16:00 Berlin time

2020-12-17 Thread julien2412

Miklos Vajna-6 wrote
> ...
> + Thunderbird Addressbook no longer connectable
> + https://bugs.documentfoundation.org/show_bug.cgi?id=138715
> + Rene removed the mork driver, needs closing?
> ...

Removing Mork => removing Thunderbird Address book but there's been too
mozab removing (I'm ok with this), should we remove all related idl eg:
offapi/com/sun/star/mozilla/MozillaBootstrap.idl or
offapi/com/sun/star/mozilla/XProfileDiscover.idl ?

Also there's the wrong named "Firebird" Address Data Source in Writer
wizards, should we remove this (or rename it if it works with Mozilla
Suite/Seamonkey but does it worth it?), knowing that the only remaining
entry would be "Other" (not very UI friendly...)?
Of course, all this should be documented in 7.2 release notes.



--
Sent from: 
http://document-foundation-mail-archive.969070.n3.nabble.com/Dev-f1639786.html
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

RE: Is there any effort or discussion yet about collaborative use of libreoffice applications?

2020-12-15 Thread julien2412

Marc Roos wrote
>>>...
> Imho there should be one 'Libre office online' the one from Libre 
> office(The Document Foundation). If collabra has a different version 
> than that should be crystal clear. Why is collabra not using the name 
> collabra oline? 
> ...

I suppose it won't change anything but I totally agree with your whole
message.



--
Sent from: 
http://document-foundation-mail-archive.969070.n3.nabble.com/Dev-f1639786.html
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

RE: Is there any effort or discussion yet about collaborative use of libreoffice applications?

2020-12-12 Thread julien2412

Hello Marc,

IMHO I think the response is here:
https://www.libreoffice.org/download/libreoffice-online
I don't know the reason but I understand it as TDF let companies like
Collabora to develop online feature above LO. 
I think you shouldn't expect much support here for collaborative use since
it's TDF.

Of course, I may be wrong, I'm just an unaffiliated casual contributor.

Julien





--
Sent from: 
http://document-foundation-mail-archive.969070.n3.nabble.com/Dev-f1639786.html
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: About tdf#138715 and future of Thunderbird address book support

2020-12-10 Thread julien2412

Lionel Élie Mamane wrote
> ...
> I seem to remember there was some code done to add a native SQlite
> SDBC driver "somewhere" (but not merged), not sure where. Or was that
> only ever discussed and never coded?
> ...

Indeed, in master
connectivity/source/drivers contains these dirs:
ado
calc
component
dbase
evoab2
file
firebird
flat
hsqldb
jdbc
macab
mork
mozab
mysqlc
mysql_jdbc
odbc
postgresql
writer

so no sqlite too.

but I also searched a branch containing sqlite with:
https://gerrit.libreoffice.org/admin/repos/core,branches/q/filter:sqlite 
nothing.
Perhaps I used wrong filter.

Now even if there's some code waiting to be merged, it should be relevant to
put it in experimental mode so people may give a try to Sqlite native
connection.
In a second time (same time but still in experimental mode in this case?),
we need also the "plumbering" so TB address book driver uses Sqlite part.
Anyway, it could be the beginning of a solution but in mid future only (6
months/1 year or more), for the present situation, the current TB address
book driver is broken for TB >= 78.

Remark: not sure if it's useful to consider those who'll stay on TB < 78. I
mean we're talking about future LO 7.2.0 (except if we remove this part too
in branch 7.1).

Julien




--
Sent from: 
http://document-foundation-mail-archive.969070.n3.nabble.com/Dev-f1639786.html
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: ESC meeting agenda: 2020-12-10 16:00 Berlin time

2020-12-09 Thread julien2412

Hello Miklos,

IMHO
http://document-foundation-mail-archive.969070.n3.nabble.com/About-tdf-138715-and-future-of-Thunderbird-address-book-support-tt4292458.html
should be discussed in ESC.
In brief, since TB, in its last version 78, migrated from Mork to Sqlite to
deal with address book and LO doesn't support Sqlite yet, should we remove
TB address book support (and also remove Mork part)?

Julien



--
Sent from: 
http://document-foundation-mail-archive.969070.n3.nabble.com/Dev-f1639786.html
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

About tdf#138715 and future of Thunderbird address book support

2020-12-09 Thread julien2412

Hello,

About 1 year ago Robert Großkopf  submitted the enhancement bugtracker
https://bugs.documentfoundation.org/show_bug.cgi?id=128977 had been created
to indicate Thunderbird address book would use in next version Sqlite
instead of Mork.

After 1 year, no one stepped in to implement Sqlite support in LO and now
with Thunderbird 78, the migration Mork->Sqlite has been done so TB address
book doesn't work any more from this version.
Robert submitted a new bugtracker
https://bugs.documentfoundation.org/show_bug.cgi?id=138715 about it.

Of course we may propose Sqlite support in LO for Gsoc but:
1) not sure a student will choose it
2) it needs a mentor and Lionel Mamane (the only expert Base dev, at least
considering https://wiki.documentfoundation.org/FindTheExpert) has almost no
more time now (I let him to confirm or not)

Do you think we may remove Thunderbird address book support (including Mork
part) in master branch (so for future 7.2.0) since most of user will have
moved to version >=78 in 6 months?
Before telling "no", that we should "wait a bit more and advertise about the
situation to try to "attract" people to implement it, consider that:
- not sure someone will step in
- he/she'll be on his/her own to implement the driver
- it'll take a bit of time to implement and test it
- there may be quite a number of bugtrackers about it

Julien



--
Sent from: 
http://document-foundation-mail-archive.969070.n3.nabble.com/Dev-f1639786.html
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Try to upgrade to Firebird 3.0.7

2020-11-10 Thread julien2412

Jan-Marek Glogowski wrote
> ...
> I was looking into building 3.0.7 when trying to build Firebird for 
> Windows Arm64. I'm really wondering, why we build Firebird on Windows 
> with a heavily patched configure, which doesn't support cross building 
> at all. Any reason not to use VS / msbuild solutions? Has anyone tried
> that?
> 
> We use msbuild for quite a few external dependencies, like Python.
> ...

I gave a try (see https://gerrit.libreoffice.org/c/core/+/105440) and it
worked on Linux after having added a typedef for a template parameter
but then it failed on Jenkins because:
- it didn't build on Mac with "Could not find acceptable ICU library" and I
didn't find why
- it didn't build on Windows with "LINK : fatal error LNK1181: cannot open
input file 'ifbclient.lib'" whereas I tried to use "ifbclient" everywhere in
existing patches. (BTW, just wonder we don't keep the original lib name)
after having found and fixed the "diff" problem on Windows (which needed
--strip-trailing-cr), quite disappointing.

Re thinking about what you indicated about Windows part, perhaps a first
step would be to simplify this part before trying to upgrade but clearly,
far too complicated for me...

Julien



--
Sent from: 
http://document-foundation-mail-archive.969070.n3.nabble.com/Dev-f1639786.html
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Question about clang-format rules

2020-11-07 Thread julien2412

Hello,

I'd like to know what to do when during trying to commit locally, I got a
message indicating:
"The above differences were found between the code to commit 
and the clang-format rules. You can apply these changes with:..."

1) Should I clang-format the patch but it means it'll make it harder to
review (to distinguish the real changes from format changes) ?

2) Should I first upload a patch just after having used clang-format rules
on files I wanted to patch? (it'll slow down the arrival of the useful
patch)

3) Excluding the files from rules checking but same pb as 2°

4) Other?

Indeed, I used --no-verify and could commit then submitted the patch but
Jenkins complained then (eg https://gerrit.libreoffice.org/c/core/+/105267)
so this option seems useless to me.

Julien



--
Sent from: 
http://document-foundation-mail-archive.969070.n3.nabble.com/Dev-f1639786.html
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: willing to contribute

2020-11-07 Thread julien2412

Hello Vikas,

Here's a link to start:
https://wiki.documentfoundation.org/Development/GetInvolved

Julien



--
Sent from: 
http://document-foundation-mail-archive.969070.n3.nabble.com/Dev-f1639786.html
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Pb with MacOs Jenkins

2020-11-02 Thread julien2412

Hello,

MacOs Jenkins failed twice on my patch
https://gerrit.libreoffice.org/c/core/+/105157
with:
...
Taking configuration values from
./distro-configs/Jenkins/macosx_clang_dbgutil
sourcing: macosx_clang_dbgutil.env
set
TMPDIR=/Users/tdf/lode/jenkins/workspace/lo_gerrit/Config/macosx_clang_dbgutil/tempdir
./autogen.sh 2>&1
autom4te: need GNU m4 1.4 or later: /usr/bin/m4
aclocal: error: echo failed with exit status: 1
Failed to run aclocal at ./autogen.sh line 196.
Build step 'Execute shell' marked build as failure
running post-script groovy...
...
I tried first a "Resume" on CI then a rebase.

Any idea what's wrong?

Julien



--
Sent from: 
http://document-foundation-mail-archive.969070.n3.nabble.com/Dev-f1639786.html
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Try to upgrade to Firebird 3.0.7

2020-11-01 Thread julien2412

Jan-Marek Glogowski wrote
> Am 01.11.20 um 14:29 schrieb julien2412:
>> ...
> Done. Uploaded Firebird-3.0.7.33374-0.tar.bz2 and removed the other 
> versions.

Thank you for the very fast feedback! :-)


Jan-Marek Glogowski wrote
>> Remark: last time, the biggest pb was to make it build on every envs (so
>> deal with env specific patches).
> 
> I was looking into building 3.0.7 when trying to build Firebird for 
> Windows Arm64. I'm really wondering, why we build Firebird on Windows 
> with a heavily patched configure, which doesn't support cross building 
> at all. Any reason not to use VS / msbuild solutions? Has anyone tried
> that?
> 
> We use msbuild for quite a few external dependencies, like Python.

I got no idea but perhaps git history may give some hints.

Julien



--
Sent from: 
http://document-foundation-mail-archive.969070.n3.nabble.com/Dev-f1639786.html
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Try to upgrade to Firebird 3.0.7

2020-11-01 Thread julien2412

Hello,

Would it be possible to make available Firebird 3.0.7 on
https://dev-www.libreoffice.org/src?

BTW, since we're only on Firebird-3.0.0.32483-0.tar.bz2, would it be
possible to remove from dev server:
- Firebird-3.0.4.33054-0.tar.bz2
- Firebird-3.0.2.32703-0.tar.bz2
- Firebird-3.0.1.32609-0.tar.bz2
since they've never been used.

I'm not sure to make it so if someone wants to work on it, don't hesitate.
Anyway, it'll be more relevant to work on 3.0.7 than on 3.0.4

Remark: about the alternative to use 4.0 Beta, it's a beta, there are more
work to do since it's a bigger change and we must deal with descendant
compatibility. Now, in the same way, if someone wants to give a try, don't
hesitate too!

Remark: last time, the biggest pb was to make it build on every envs (so
deal with env specific patches).

Julien



--
Sent from: 
http://document-foundation-mail-archive.969070.n3.nabble.com/Dev-f1639786.html
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

[SOLVED] Re: git indicates "helpcontent2" modified

2020-10-08 Thread julien2412

Ilmari Lauhakangas wrote
> Do this while in the core repository:
> 
> git submodule update
> ...

It worked! Thank you! (I'll also keep this page in my local notes)



--
Sent from: 
http://document-foundation-mail-archive.969070.n3.nabble.com/Dev-f1639786.html
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

gerrit Jenkins Android machine fails

2020-10-06 Thread julien2412

Hello,

I resumed build 2 or 3 times for
https://gerrit.libreoffice.org/c/core/+/104040 but Jenkins Android fails
with:
ERROR: Error fetching remote repo 'origin'
hudson.plugins.git.GitException: Failed to fetch from
https://git.libreoffice.org/core
at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:996)
at hudson.plugins.git.GitSCM.retrieveChanges(GitSCM.java:1237)
at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1297)
at hudson.scm.SCM.checkout(SCM.java:505)
at hudson.model.AbstractProject.checkout(AbstractProject.java:1206)
at
hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:637)
at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86)
at
hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:509)
at hudson.model.Run.execute(Run.java:1894)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
at hudson.model.ResourceController.execute(ResourceController.java:97)
at hudson.model.Executor.run(Executor.java:428)
Caused by: hudson.plugins.git.GitException: Command "git config
remote.origin.url https://git.libreoffice.org/core; returned status code 4:
stdout: 
stderr: error: failed to write new configuration file
/home/tdf/lode/jenkins/workspace/android_x86/.git/config.lock

at
org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:2450)
at
org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:2380)
at
org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:2376)
at
org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommand(CliGitAPIImpl.java:1923)
at
org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommand(CliGitAPIImpl.java:1935)
at
org.jenkinsci.plugins.gitclient.CliGitAPIImpl.setRemoteUrl(CliGitAPIImpl.java:1549)
at hudson.plugins.git.GitAPI.setRemoteUrl(GitAPI.java:161)
at sun.reflect.GeneratedMethodAccessor60.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
hudson.remoting.RemoteInvocationHandler$RPCRequest.perform(RemoteInvocationHandler.java:936)
at
hudson.remoting.RemoteInvocationHandler$RPCRequest.call(RemoteInvocationHandler.java:909)
at
hudson.remoting.RemoteInvocationHandler$RPCRequest.call(RemoteInvocationHandler.java:860)
at hudson.remoting.UserRequest.perform(UserRequest.java:211)
at hudson.remoting.UserRequest.perform(UserRequest.java:54)
at hudson.remoting.Request$2.run(Request.java:375)
at
hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:73)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
Suppressed: hudson.remoting.Channel$CallSiteStackTrace: Remote call to 
hc-3
at 
hudson.remoting.Channel.attachCallSiteStackTrace(Channel.java:1800)
at
hudson.remoting.UserRequest$ExceptionResponse.retrieve(UserRequest.java:357)
at hudson.remoting.Channel.call(Channel.java:1001)
at
hudson.remoting.RemoteInvocationHandler.invoke(RemoteInvocationHandler.java:286)
at com.sun.proxy.$Proxy66.setRemoteUrl(Unknown Source)
at
org.jenkinsci.plugins.gitclient.RemoteGitImpl.setRemoteUrl(RemoteGitImpl.java:299)
at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:984)
at hudson.plugins.git.GitSCM.retrieveChanges(GitSCM.java:1237)
at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1297)
at hudson.scm.SCM.checkout(SCM.java:505)
at 
hudson.model.AbstractProject.checkout(AbstractProject.java:1206)
at
hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:637)
at 
jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86)
at
hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:509)
at hudson.model.Run.execute(Run.java:1894)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
at 
hudson.model.ResourceController.execute(ResourceController.java:97)
at hudson.model.Executor.run(Executor.java:428)

Any idea?

Julien



--
Sent from: 
http://document-foundation-mail-archive.969070.n3.nabble.com/Dev-f1639786.html
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

git indicates "helpcontent2" modified

2020-10-06 Thread julien2412

Hello,

After having recreated from scratch my local repo, I got now:
On branch master
Your branch is up to date with 'origin/master'.

Changes not staged for commit:
  (use "git add ..." to update what will be committed)
  (use "git restore ..." to discard changes in working directory)
modified:   helpcontent2 (new commits)

with:
git diff
diff --git a/helpcontent2 b/helpcontent2
index a9deae83c3b1..5494e02b2527 16
--- a/helpcontent2
+++ b/helpcontent2
@@ -1 +1 @@
-Subproject commit a9deae83c3b11cdb138069b97f3cd6111ff6a19f
+Subproject commit 5494e02b2527f27a8cfbbd0a4a125443f3851715

whereas I got:
julien@debianamd:~/lo/libreoffice$ git branch
* master

julien@debianamd:~/lo/libreoffice/helpcontent2$ git branch
* master

julien@debianamd:~/lo/libreoffice$ git pull -r
load pubkey "/home/julien/.ssh/id_rsa": invalid format
Already up to date.

julien@debianamd:~/lo/libreoffice/helpcontent2$ git status
On branch master
Your branch is up to date with 'origin/master'.

nothing to commit, working tree clean

julien@debianamd:~/lo/libreoffice/helpcontent2$ git pull -r
load pubkey "/home/julien/.ssh/id_rsa": invalid format
Already up to date.

Thanks to gitk, I got extra info:
 Local uncommitted changes, not checked in to index

- helpcontent2
-
Submodule helpcontent2 a9deae83c3b1..5494e02b2527:
  > tdf#96446 Fix Librelogo code example
  > Fix duplicate information on AVERAGEIF
  > tdf#137196 update help for Format Page tab for all modules
  > tdf#133403 update PDF export help pages
  > Revise explanation in File - Close help page
  > tdf#131305 Add note about shortcut for editing a comment
  > tdf#137084  add the More Breaks submenu to Insert help page
  > Update DocInformation (field) help page
  > Fix Help build
  > Workaround for buggy SVG export of image
  > tdf#132643 Translate German section IDs
  > tdf#132643 Translate German section IDs
...
But I don't know what to do with this.

It's appeared some days ago and I don't know why.
It's not blocking for me but quite annoying.

Any idea?

Julien



--
Sent from: 
http://document-foundation-mail-archive.969070.n3.nabble.com/Dev-f1639786.html
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Stuck trying to recreate local repo from scratch

2020-10-03 Thread julien2412

Hello,

This morning for a reason I ignore, git status indicated me helpcontent2 had
to be updated.
I tried different things but got stuck so I removed the whole directory and
downloaded again the core repo.
But now I can't get "translations" repo when trying building with make.
I've got this in .git/config:
[core]
repositoryformatversion = 0
filemode = true
bare = false
logallrefupdates = true
[remote "origin"]
url = ssh://serval2...@gerrit.libreoffice.org:29418/core.git
#url = ssh://logerrit/core
fetch = +refs/heads/*:refs/remotes/origin/*
pushurl = ssh://logerrit/core
[branch "master"]
remote = origin
merge = refs/heads/master
[submodule "translations"]
active = true
url = ssh://serval2...@gerrit.libreoffice.org:29418/translations.git
#url = https://gerrit.libreoffice.org/translations
[submodule "dictionaries"]
active = true
url = ssh://serval2...@gerrit.libreoffice.org:29418/dictionaries.git
#url = https://gerrit.libreoffice.org/dictionaries
[submodule "helpcontent2"]
active = true
url = ssh://serval2...@gerrit.libreoffice.org:29418/help.git
#url = https://gerrit.libreoffice.org/help
[protocol]
version = 2

I tried ssh part + https://gerrit, impossible to retrieve translations after
several minutes, it's just stuck.

Of course, I took a look at
https://wiki.documentfoundation.org/Development/gerrit/setup and my
~/.ssh/config hasn't changed.

./logerrit test seems stuck but when I do "Ctrl-C", I get:
Your gerrit setup was successful!

git pull -r
gives:
load pubkey "/home/julien/.ssh/id_rsa": invalid format
But I had already this error since several months ago, never understood how
to get rid of it so let it as it was since it wasn't prevented me from
updating local repo.

Any idea what I missed?

Julien



--
Sent from: 
http://document-foundation-mail-archive.969070.n3.nabble.com/Dev-f1639786.html
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Interested in open source for libre office

2020-09-26 Thread julien2412

Hello Nikhil,

You can start with this link:
https://wiki.documentfoundation.org/Development/GetInvolved

Julien



--
Sent from: 
http://document-foundation-mail-archive.969070.n3.nabble.com/Dev-f1639786.html
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: ESC meeting agenda: 2020-09-17 16:00 Berlin time

2020-09-17 Thread julien2412

I don't know if it must be indicated in the ESC because it's public API
change but, just for information, I remove unused and deprecated
sal_Char/sal_sChar/sal_uChar from include/sal/types.h. (see
http://document-foundation-mail-archive.969070.n3.nabble.com/About-removing-long-time-deprecated-types-from-public-API-tt4287268.html)

Julien



--
Sent from: 
http://document-foundation-mail-archive.969070.n3.nabble.com/Dev-f1639786.html
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

[SOLVED] Re: About removing long time deprecated types from public API

2020-09-17 Thread julien2412

The types have been removed and I put a comment in
https://wiki.documentfoundation.org/ReleaseNotes/7.1 in SDK part.

Thank you Stephan!



--
Sent from: 
http://document-foundation-mail-archive.969070.n3.nabble.com/Dev-f1639786.html
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Gdb + deprecated Python + gdb._execute_unwinders function is missing

2020-09-16 Thread julien2412

Hello,

Since yesterday and I don't know why, when launching make debugrun, I got:
mkdir -p /home/julien/lo/libreoffice/instdir
/home/julien/lo/libreoffice/solenv/bin/install-gdb-printers -a
/home/julien/lo/libreoffice/instdir -c
make -j 12  -rs -f /home/julien/lo/libreoffice/Makefile.gbuild   debugrun
Python Exception  the imp module is deprecated
in favour of importlib; see the module's documentation for alternative uses: 
gdb: warning: 
Could not load the Python gdb module from `/usr/share/gdb/python'.
Limited Python support is available from the _gdb module.
Suggest passing --data-directory=/path/to/gdb/data-directory.

Once I get gdb command and type run --calc, I got, lots of this kind:
Starting program: /home/julien/lo/libreoffice/instdir/program/soffice.bin
--calc
Traceback (most recent call last):
  File "/home/julien/lo/libreoffice/instdir/program/libuno_sal.so.3-gdb.py",
line 14, in 
import gdb
  File "/usr/share/gdb/python/gdb/__init__.py", line 23, in 
from imp import reload
  File "/usr/lib/python3.8/imp.py", line 31, in 
warnings.warn("the imp module is deprecated in favour of importlib; "
DeprecationWarning: the imp module is deprecated in favour of importlib; see
the module's documentation for alternative uses
Traceback (most recent call last):
  File
"/usr/share/gdb/auto-load/usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.28-gdb.py",
line 18, in 
import gdb
  File "/usr/share/gdb/python/gdb/__init__.py", line 23, in 
from imp import reload
  File "/usr/lib/python3.8/imp.py", line 31, in 
warnings.warn("the imp module is deprecated in favour of importlib; "
DeprecationWarning: the imp module is deprecated in favour of importlib; see
the module's documentation for alternative uses

and at the end:
Python Exception  Installation error:
gdb._execute_unwinders function is missing: 
Python Exception  Installation error:
gdb._execute_unwinders function is missing: 

I'm on Debian testing updated every day.
I installed python3-gdbm and python3-gdbm-dbg

I runned "./autogen.sh && make clean && make" just to be sure there wasn't
any wrong remnants.

Any idea?

Julien



--
Sent from: 
http://document-foundation-mail-archive.969070.n3.nabble.com/Dev-f1639786.html
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

[SOLVED] Re: About use of sal_IntPtr for FontList::GetSizeAry, aStdSizeAry and mpSizeAry (svtools)

2020-09-12 Thread julien2412

Caolán McNamara wrote
>> ...
> These are font heights, and IMO I feel a humble int is sufficient for
> their maximum range (https://gerrit.libreoffice.org/c/core/+/102466) on
> looking at what goes into them

Ok then, let's put this thread to SOLVED.



--
Sent from: 
http://document-foundation-mail-archive.969070.n3.nabble.com/Dev-f1639786.html
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: About removing long time deprecated types from public API

Dumb me!
I had read the comment for sal_sChar (@deprecated use plain `signed char`
instead)
instead of sal_Char (@deprecated use plain `char` instead)

Sorry for the noise, I'm gonna test with the right replace :-)



--
Sent from: 
http://document-foundation-mail-archive.969070.n3.nabble.com/Dev-f1639786.html
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: About removing long time deprecated types from public API

sberg wrote
>> ...
> sounds ok at least to me

For replace sal_uChar, I could build and use "make check" for concerned
modules, so I submitted the patch on gerrit.

But replacing sal_Char triggers a lot of errors.
First one is:
In file included from /home/julien/lo/libreoffice/include/rtl/string.hxx:43:
/home/julien/lo/libreoffice/include/rtl/stringconcat.hxx:384:59: error: no
matching function for call to 'rtl_str_valueOfInt32'
OStringNumber(number_t i, sal_Int16 radix) { length =
rtl_str_valueOfInt32(buf, i, radix); }
 
^~~~
/home/julien/lo/libreoffice/include/rtl/string.h:623:34: note: candidate
function not viable: no known conversion from 'char [33]' to 'signed char *'
for 1st argument
SAL_DLLPUBLIC sal_Int32 SAL_CALL rtl_str_valueOfInt32(
 ^
So I first tried static_cast buf to "signed char*" but it's incorrect. So I
tried these changes:
diff --git a/include/rtl/stringconcat.hxx b/include/rtl/stringconcat.hxx
index e2cba5d86f0d..eadaae6eb2bb 100644
--- a/include/rtl/stringconcat.hxx
+++ b/include/rtl/stringconcat.hxx
@@ -366,14 +366,14 @@ template 
struct OStringNumberBase
 // OString::number(value).getStr() is very common (writing xml code,
...),
 // so implement that one also here, to avoid having to explicitly to
convert
 // to OString in all such places
-const char * getStr() const SAL_RETURNS_NONNULL { return buf; }
+const signed char * getStr() const SAL_RETURNS_NONNULL { return buf; }
 OStringNumber&& toAsciiUpperCase()
 {
 rtl_str_toAsciiUpperCase_WithLength(buf, length);
 return std::move(*static_cast*>(this));
 }
 operator std::string_view() const { return std::string_view(buf,
length); }
-char buf[nBufSize];
+signed char buf[nBufSize];
 sal_Int32 length;
 };

but not sure if it's ok and I still got plenty errors.

In brief, it seems I won't be able to get rid of sal_Char :-(

Julien




--
Sent from: 
http://document-foundation-mail-archive.969070.n3.nabble.com/Dev-f1639786.html
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: About removing long time deprecated types from public API

sberg wrote
>> ...
> So if you see a benefit in doing this particular change:  I'd say, mark 
> the change as "[API CHANGE]" in the commit message, get it in, and 
> document the backwards incompatible change at 
> https://wiki.documentfoundation.org/ReleaseNotes/7.1#API_Changes;.

Great!!!

I added [API CHANGE] to the change
https://gerrit.libreoffice.org/c/core/+/102436

Here the next commits I thought:
- a commit to replace sal_uChar from all locations except
include/sal/types.h
 (only 5 locations)
- a commit to replace sal_Char from all locations except include/sal/types.h
(202 locations so we'll use some automatic tool)
For these, I'll build locally + use "make check" before submitting.
then:
- a commit to remove sal_uChar + sal_Char from include/sal/types.h including
[API CHANGE]

Once all is pushed, I'll add the information in release notes.

Does it sound ok for you or do you want I merge/split some of the commits?

Julien



--
Sent from: 
http://document-foundation-mail-archive.969070.n3.nabble.com/Dev-f1639786.html
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

About removing long time deprecated types from public API