Build failed in Jenkins: Support and maintenance jobs » Check-author-email-in-commit-log #48

[ci-lyx]

https://ci.inria.fr/lyx/job/support/job/Check-author-email-in-commit-log/48/Changes:

[spitz] Fix child document regex in scanLogFile

[spitz] tex2lyx: normalize bib and bst paths

[milde] lyx2lyx fixes and cleanup.

[forenr] Avoid an infinite loop

[sanda] Cosmetics per JMarc's suggestions.

[spitz] Fix Windows compiler warning about double declaration of "it"

[kornel] Cmake build: Allow cross-compiling with mingw again

[spitz] Fix race condition in processFuncRequestQueue

[spitz] Disable CheckTeX while buffer is processed

[spitz] amend 71fea633266

[uwestoehr] ru.po: is now 100% translated

[spitz] Disable BUFFER_EXPORT and BUFFER_EXPORT_AS while buffer is processed

[spitz] biblatex-natbib.citeengine: Remove erroneous blank

[jpc]Remove sections 6.7 and 6.4 from Additional manual (obsolete

[lasgouttes] Implement buffer-anonymize more efficiently

[lasgouttes] Remove template AGUTeX.lyx from Makefile

[lasgouttes] Use parMetrics to access the par_metrics_ map

[lasgouttes] There is actually a home for obsolete templates in Makefile

[spitz] Updated Basque localization by Iñaki Larrañaga Murgoitio

[uwestoehr] Customization.lyx: distribute all tracked changes

[uwestoehr] ru.po: some corrections by Yuriy

[sanda] Fixing painting regression - chapter top spacing.

[sanda] * lib/layouttranslations, sync with 2.3

[rgheck] Fix crash when citeengine is unknown.

[rgheck] Also fix chapter layout in tufte-book.

[spitz] Updated Basque localization by Iñaki Larrañaga Murgoitio

[uwestoehr] UserGuide.lyx: document the removal of the pixmap cache for all

[spitz] Disable unsupported ref types in mathed.

[skostysh] ANNOUNCE: copy from current 2.3.x branch

--
Started by timer
Building remotely on lyx-linux1 (linux) in workspace 

Wiping out workspace first.
Cloning the remote Git repository
Cloning repository git://git.lyx.org/lyx.git
 > git init 
 > 
 >  # timeout=10
Fetching upstream changes from git://git.lyx.org/lyx.git
 > git --version # timeout=10
 > git fetch --tags --progress git://git.lyx.org/lyx.git 
 > +refs/heads/*:refs/remotes/origin/*
 > git config remote.origin.url git://git.lyx.org/lyx.git # timeout=10
 > git config --add remote.origin.fetch +refs/heads/*:refs/remotes/origin/* # 
 > timeout=10
 > git config remote.origin.url git://git.lyx.org/lyx.git # timeout=10
Fetching upstream changes from git://git.lyx.org/lyx.git
 > git fetch --tags --progress git://git.lyx.org/lyx.git 
 > +refs/heads/*:refs/remotes/origin/*
 > git rev-parse refs/remotes/origin/master^{commit} # timeout=10
 > git rev-parse refs/remotes/origin/origin/master^{commit} # timeout=10
Checking out Revision 20d1b9d2266ae9a810a73e63efdfe5814f7a02e5 
(refs/remotes/origin/master)
 > git config core.sparsecheckout # timeout=10
 > git checkout -f 20d1b9d2266ae9a810a73e63efdfe5814f7a02e5
 > git rev-list f15cb2c40dd84f3470e8f64f7062fb72068fb11d # timeout=10
[Check-author-email-in-commit-log] $ /bin/sh -xe 
/tmp/hudson7349515992410787400.sh
+ printf \n\nShow disk usage. Not needed, just for information\n


Show disk usage. Not needed, just for information
+ df -h / /builds /home /builds/workspace
Filesystem  Size  Used Avail Use% Mounted on
/dev/sda118G   14G  3.7G  79% /
/dev/sda118G   14G  3.7G  79% /
/dev/sda118G   14G  3.7G  79% /
/dev/vda 40G   24G   14G  63% /builds/workspace
+ git status
HEAD detached at 20d1b9d
nothing to commit, working directory clean
+ SCRIPT=development/CI/bin/check_git_log_for_unrecognised_email_addresses.sh
+ 
EXPECTED_HASH=1330d9fca5e385e9de8933cbf6d39107b2f6af1cf7ca3175babfd4e5ab46b024ff2d98c7c8630b362be506da9376f9262a524755f9acf655d83dcce8a564
+ printf \n\nExecute script that checks commit log\n


Execute script that checks commit log
+ development/CI/bin/check_git_log_for_unrecognised_email_addresses.sh 
--check-hash 
1330d9fca5e385e9de8933cbf6d39107b2f6af1cf7ca3175babfd4e5ab46b024ff2d98c7c8630b362be506da9376f9262a524755f9acf655d83dcce8a564
Hash mismatch:
  Desired: 
1330d9fca5e385e9de8933cbf6d39107b2f6af1cf7ca3175babfd4e5ab46b024ff2d98c7c8630b362be506da9376f9262a524755f9acf655d83dcce8a564
  Current: 
73f7eb10b187d77a69526cb374742fdf40b7539aa95c42496ace4ee1de1ee4d6820885f850957718ed51210095b72632910a0c2529393ce2b1f41a5308b0a012
Latest log:
c070c2f1f8 2018-01-10 02:38:31 +0100 name=Uwe Stöhr email=uwesto...@web.de
bb650bf8c2 2018-01-10 02:12:40 +0100 name=Uwe Stöhr email=uwesto...@web.de
26acdd27c4 2017-07-30 00:54:12 +0200 name=Christian Ridderström 
email=christian.ridderst...@profoto.com
e30f3d76d2 2017-07-23 13:11:54 +0200 name=Christian Ridderström 
email=christian.ridderst...@profoto.com
5078448111 2017-07-17 22:23:17 +0200 name=Christian Ridderström 
email=christian.ridderst...@profoto.com
0d565f7b35 2017-07-11 15:28:06 +0200 name=Jean-Marc 

Re: LyX version 2.3.0rc2 available

[Scott Kostyshak]

On Thu, Feb 01, 2018 at 01:58:54PM +, Joel Kulesza wrote:

> I would include the link to the mirror listing. Otherwise, I can imagine
> frustration of having a slow/failed download causing me to then go hunt for
> a better alternative on the website (for a new user, who may not be totally
> familiar with it).

I added the link to the list of mirrors at 37b5aa1e. I think this was a
good change, especially since the upstream FTP was down briefly [1]. I
do not think it is worth it to specify that the upstream FTP is based in
Paris. I'm not close to Paris and have not found the mirror to be slow,
and we have not gotten much feedback about the FTP being slow.

Scott


[1]
https://www.mail-archive.com/search?l=mid=AM3PR04MB1297EE16DF1C3AA9FA54445CDEF60%40AM3PR04MB1297.eurprd04.prod.outlook.com


signature.asc
Description: PGP signature

Re: [LyX/master] Unify graphics-groups inside marked block functionality.

[Richard Heck]

On 02/15/2018 05:52 AM, Pavel Sanda wrote:
> Pavel Sanda wrote:
>> commit b88ed81e7f1d2f59bb606351d95e093380b4eead
>> Author: Pavel Sanda 
>> Date:   Thu Feb 8 21:33:37 2018 +0100
>>
>> Unify graphics-groups inside marked block functionality.
>> 
>> Fixes #11026.
> Richard, can this go to 2.3.2? P

Yes, sure.

rh

Re: integral upper limit adjacent to integral sign

[Pavel Sanda]

Pavel Sanda wrote:
> Jean-Marc Lasgouttes wrote:
> > Le 15 février 2018 16:32:23 GMT+01:00, Jean-Marc Lasgouttes 
> >  a écrit :
> > 
> > >>I can try to prepare that. What character you want me to paste there?
> > >>I can't take 'f' from esint, there is no 'f' included. Pavel
> > >
> > >The integral at position 1.
> > 
> > And glyph number 4, I think.
> 
> Try this one:
> 195.113.26.193/~sanda/junk/DejaVuSerif-Italic.ttf
> At f position you have esint glyph 1, at 'g' position you have glyph 4.

One difference I could immediatelly spot was that dejavu italic has
set 'angle' -11 degrees, because it's italic font, while we have 0
for esint if it matters for your debug...

Pavel

Re: integral upper limit adjacent to integral sign

[Pavel Sanda]

Jean-Marc Lasgouttes wrote:
> Le 15 février 2018 16:32:23 GMT+01:00, Jean-Marc Lasgouttes 
>  a écrit :
> 
> >>I can try to prepare that. What character you want me to paste there?
> >>I can't take 'f' from esint, there is no 'f' included. Pavel
> >
> >The integral at position 1.
> 
> And glyph number 4, I think.

Try this one:
195.113.26.193/~sanda/junk/DejaVuSerif-Italic.ttf
At f position you have esint glyph 1, at 'g' position you have glyph 4.
Pavel

Re: integral upper limit adjacent to integral sign

[Jean-Marc Lasgouttes]

Le 15 février 2018 16:32:23 GMT+01:00, Jean-Marc Lasgouttes 
 a écrit :

>>I can try to prepare that. What character you want me to paste there?
>>I can't take 'f' from esint, there is no 'f' included. Pavel
>
>The integral at position 1.

And glyph number 4, I think.

JMarc

Re: integral upper limit adjacent to integral sign

[Jean-Marc Lasgouttes]

Le 15 février 2018 16:23:16 GMT+01:00, Pavel Sanda  a écrit :
>Jean-Marc Lasgouttes wrote:
>> Le 15/02/2018 ?? 16:13, Pavel Sanda a écrit :
>>> So what about copy-paste esint(f) into DejaVuSerif-Italic via
>fontforge
>>> and check what happens.
>>> If there is some metainfo set wrong we could use Dejavu as a
>skeleton
>>> and copy our symbols there...
>>
>> I never used fontforge to modify a font...
>
>I can try to prepare that. What character you want me to paste there?
>I can't take 'f' from esint, there is no 'f' included. Pavel

The integral at position 1.

JMarc

Re: integral upper limit adjacent to integral sign

[Pavel Sanda]

Jean-Marc Lasgouttes wrote:
> Le 15/02/2018 ?? 16:13, Pavel Sanda a écrit :
>> So what about copy-paste esint(f) into DejaVuSerif-Italic via fontforge
>> and check what happens.
>> If there is some metainfo set wrong we could use Dejavu as a skeleton
>> and copy our symbols there...
>
> I never used fontforge to modify a font...

I can try to prepare that. What character you want me to paste there?
I can't take 'f' from esint, there is no 'f' included. Pavel

Re: integral upper limit adjacent to integral sign

[Jean-Marc Lasgouttes]

Le 15/02/2018 à 16:13, Pavel Sanda a écrit :

So what about copy-paste esint(f) into DejaVuSerif-Italic via fontforge
and check what happens.
If there is some metainfo set wrong we could use Dejavu as a skeleton
and copy our symbols there...


I never used fontforge to modify a font...

JMarc

Re: integral upper limit adjacent to integral sign

[Pavel Sanda]

Jean-Marc Lasgouttes wrote:
> Le 14/02/2018 ?? 17:11, Pavel Sanda a écrit :
>> Jean-Marc Lasgouttes wrote:
>>> I took a look at the Qt4 and Qt5 code and did not see a difference. It
>>> might be that our fonts are malformed.
>> I loaded esint10.ttf into fontforge and when I go to Metrics->set 
>> L/RBearings
>> of integral sign (#1) I see the value 113.5.
>> I doesn't look as what your log stated or do I read it wrong?
>
> You read it right, ttfdump says the same in the glyf/hmtx  tables.
>
> My problem if the DejaVuSerif-Italic, where I take my italic f, has similar 
> values, but Qt return good results. I suspect that there are other values 
> somewhere in the font that conflict with our metrics.

So what about copy-paste esint(f) into DejaVuSerif-Italic via fontforge
and check what happens.
If there is some metainfo set wrong we could use Dejavu as a skeleton
and copy our symbols there...

Pavel

Re: integral upper limit adjacent to integral sign

[Jean-Marc Lasgouttes]

Le 14/02/2018 à 17:11, Pavel Sanda a écrit :

Jean-Marc Lasgouttes wrote:

I took a look at the Qt4 and Qt5 code and did not see a difference. It
might be that our fonts are malformed.


I loaded esint10.ttf into fontforge and when I go to Metrics->set L/RBearings
of integral sign (#1) I see the value 113.5.
I doesn't look as what your log stated or do I read it wrong?


You read it right, ttfdump says the same in the glyf/hmtx  tables.

My problem if the DejaVuSerif-Italic, where I take my italic f, has 
similar values, but Qt return good results. I suspect that there are 
other values somewhere in the font that conflict with our metrics.


JMarc

Re: integral upper limit adjacent to integral sign

[Jean-Marc Lasgouttes]

Le 14/02/2018 à 16:50, Pavel Sanda a écrit :

Jean-Marc Lasgouttes wrote:

I have tried to run ttfdump on the ttf files, and it shows properly
negative right bearings for both fonts. At this point, I give up :)


Maybe we can try bipartisan attempt on Qt bug tracking system.
I recently filled up the bug for Qt5 not rendering characters
for certain codepoints, maybe we get more attention if we report
this as a part of the bug(?).

https://bugreports.qt.io/browse/QTBUG-66266


I think it should be a different bug. But I am not sure yet whether it 
is a bug in

- our fonts
- freetype
- Qt itself.

JMarc

Re: Staging Branches

[Pavel Sanda]

Jean-Marc Lasgouttes wrote:
>>> can we merge the painting branch into 2.3.1 staging?  I'm inclusively
>>> working on master without larger issues for quite some time now. That does
>>> not say anything about mac/win arch, but the sooner we start testing the
>>> better.
>> I'd be happy to have it in 2.3.2-staging. At this point, 2.3.1 is reserved
>> for emergencies, more or less.
>
> Fine, I have done that now. Please test and complain.

Cool, I am switching from master to 2.3.2 from now on.
Pavel

Re: Staging Branches

[Jean-Marc Lasgouttes]

Le 14/02/2018 à 18:54, Richard Heck a écrit :

can we merge the painting branch into 2.3.1 staging?
I'm inclusively working on master without larger issues for quite some time
now. That does not say anything about mac/win arch, but the sooner we start
testing the better.


I'd be happy to have it in 2.3.2-staging. At this point, 2.3.1 is
reserved for emergencies, more or less.


Fine, I have done that now. Please test and complain.

JMarc

Re: [LyX/master] Implement buffer-anonymize more efficiently

[Jean-Marc Lasgouttes]

Le 15/02/2018 à 11:29, Jean-Marc Lasgouttes a écrit :
Pavel is supposed to push his original work on 2.3.1. I am waiting to 
see whether this happens.


Everything is in place now.

JMarc

Re: [LyX/master] Unify graphics-groups inside marked block functionality.

[Pavel Sanda]

Pavel Sanda wrote:
> commit b88ed81e7f1d2f59bb606351d95e093380b4eead
> Author: Pavel Sanda 
> Date:   Thu Feb 8 21:33:37 2018 +0100
> 
> Unify graphics-groups inside marked block functionality.
> 
> Fixes #11026.

Richard, can this go to 2.3.2? P

> 
> https://www.mail-archive.com/lyx-devel@lists.lyx.org/msg203683.html
> ---
>  lib/ui/stdcontext.inc |1 +
>  src/BufferView.cpp|   45 +
>  src/FuncCode.h|3 ++-
>  src/LyXAction.cpp |   11 +++
>  4 files changed, 59 insertions(+), 1 deletions(-)
> 
> diff --git a/lib/ui/stdcontext.inc b/lib/ui/stdcontext.inc
> index 3e49092..9acf334 100644
> --- a/lib/ui/stdcontext.inc
> +++ b/lib/ui/stdcontext.inc
> @@ -358,6 +358,7 @@ Menuset
>   Item "Apply Last Text Style|A" "textstyle-apply"
>   Submenu "Text Style|x" "edit_textstyles"
>   Item "Paragraph Settings...|P" "layout-paragraph"
> + OptItem "Unify Graphics Groups|U" "graphics-unify"
>   LanguageSelector
>   Separator
>   Item "Fullscreen Mode" "ui-toggle fullscreen"
> diff --git a/src/BufferView.cpp b/src/BufferView.cpp
> index b2e3186..ad8ed46 100644
> --- a/src/BufferView.cpp
> +++ b/src/BufferView.cpp
> @@ -1151,6 +1151,10 @@ bool BufferView::getStatus(FuncRequest const & cmd, 
> FuncStatus & flag)
>   flag.setEnabled(true);
>   break;
>  
> + case LFUN_GRAPHICS_UNIFY:
> + flag.setEnabled(cur.selection());
> + break;
> +
>   case LFUN_WORD_FINDADV: {
>   FindAndReplaceOptions opt;
>   istringstream iss(to_utf8(cmd.argument()));
> @@ -1697,6 +1701,47 @@ void BufferView::dispatch(FuncRequest const & cmd, 
> DispatchResult & dr)
>   break;
>   }
>  
> + case LFUN_GRAPHICS_UNIFY: {
> +
> + cur.recordUndoFullBuffer();
> +
> + DocIterator from, to;
> + from = cur.selectionBegin();
> + to = cur.selectionEnd();
> +
> + string newId = cmd.getArg(0);
> + bool fetchId=newId.empty(); //if we wait for groupId from first 
> graphics inset
> +
> + InsetGraphicsParams grp_par;
> + InsetGraphics::string2params(graphics::getGroupParams(buffer_, 
> newId), buffer_, grp_par);
> +
> + if (!from.nextInset())  //move to closest inset
> + from.forwardInset();
> +
> + while (!from.empty() && from < to) {
> + Inset * inset = from.nextInset();
> + if (!inset)
> + break;
> + if (inset->lyxCode() == GRAPHICS_CODE) {
> + InsetGraphics * ig = inset->asInsetGraphics();
> + if (!ig)
> + break;
> + InsetGraphicsParams inspar = ig->getParams();
> + if (fetchId) {
> + grp_par = inspar;
> + fetchId = false;
> +
> + } else {
> + grp_par.filename = inspar.filename;
> + ig->setParams(grp_par);
> + }
> + }
> + from.forwardInset();
> + }
> + dr.screenUpdate(Update::Force); //needed if triggered from 
> context menu
> + break;
> + }
> +
>   case LFUN_STATISTICS: {
>   DocIterator from, to;
>   if (cur.selection()) {
> diff --git a/src/FuncCode.h b/src/FuncCode.h
> index 4a59831..cce61f0 100644
> --- a/src/FuncCode.h
> +++ b/src/FuncCode.h
> @@ -476,7 +476,8 @@ enum FuncCode
>   LFUN_DEVEL_MODE_TOGGLE, // lasgouttes 20170723
>   //370
>   LFUN_EXPORT_CANCEL, // rgh, 20171227
> - LFUN_BUFFER_ANONYMIZE, // sanda, 20180201
> + LFUN_BUFFER_ANONYMIZE,  // sanda, 20180201
> + LFUN_GRAPHICS_UNIFY,// sanda, 20180207
>   LFUN_LASTACTION // end of the table
>  };
>  
> diff --git a/src/LyXAction.cpp b/src/LyXAction.cpp
> index 193c822..a4bc7d1 100644
> --- a/src/LyXAction.cpp
> +++ b/src/LyXAction.cpp
> @@ -3555,6 +3555,17 @@ void LyXAction::init()
>   */
>   { LFUN_SET_GRAPHICS_GROUP, "set-graphics-group", Noop, Edit },
>  
> +/*!
> + * \var lyx::FuncCode lyx::LFUN_GRAPHICS_UNIFY
> + * \li Action: Set the same group for all graphics insets in the marked 
> block.
> + * \li Syntax: graphics-unify []
> + * \li Params: : Id for an existing group. In case the Id is an empty 
> string,
> +the group Id from the first graphics inset will be 
> used.
> + * \li Origin: sanda, 7 Feb 2018
> + * \endvar
> + */
> + { LFUN_GRAPHICS_UNIFY, "graphics-unify", Noop, Edit },
> +

Re: [LyX/master] Implement buffer-anonymize more efficiently

[Jean-Marc Lasgouttes]

Le 14/02/2018 à 16:13, Richard Heck a écrit :

On 02/12/2018 08:39 AM, Jean-Marc Lasgouttes wrote:

Le 12/02/2018 à 14:38, Jean-Marc Lasgouttes a écrit :

commit 1dba36c7cec6aeec2576e7a99e2967e867076a01
Author: Jean-Marc Lasgouttes 
Date:   Wed Feb 7 15:35:46 2018 +0100

  Implement buffer-anonymize more efficiently
   The work is done now in Paragraph::anonymize().
   Move the handling of the lfun to Buffer class.


Richard, this is candidate for 2.3.2 (no hurry).


I have just created a 2.3.2-staging branch. (As usual, I'm worried about
forgetting things.) Please commit there.


Pavel is supposed to push his original work on 2.3.1. I am waiting to 
see whether this happens.


JMarc

Re: Staging Branches

[Pavel Sanda]

Pavel Sanda wrote:
> Richard Heck wrote:
> > If we don't need to do anything
> > super-fast, then I'll just merge 2.3.2-staging into 2.3.1-staging.
> 
> I see, sounds good. Pavel

When I think more about it though, if *getting the branch tested* from other
devs is important goal of yours, then the best is just to have single branch
2.3.x (after releasing 2.3.0) and nothing else.
If *critical* thing appear (I can rember only one case of that during all the
years) then you can branch out directly from 2.3.0 and fix it there.

Pavel

Re: Basque translation

[Pavel Sanda]

I??aki Larra??aga Murgoitio wrote:
> > (*):
> > "Property"
> > "Solution"
> > "Listing"
> > "Listings"
> > "List of Listings"
> > "see equation[[nomencl]]"
> > "page[[nomencl]]"
> > 
> 
> 
> Are those new messages into PO file? Anyway, let me translate them to basque 
> for you: (english : basque)

Yes, all these changes have to be done in  .po file first, we then regenerate 
the file lib/layouttranslations
from it. You can check "eu" section in the resulting file in your tree or here:
http://git.lyx.org/?p=lyx.git;a=blob;f=lib/layouttranslations;h=f350f2327c7132cef303192426edd95987d7b045;hb=HEAD
 
> I need some context for ???property??? term, does it refer to something???s 
> owner?
> 
>   Property : Jabetza
> 
> other way it should translate as:
> 
>   Property : Propietatea

Here context is mathematical and you already have Propietatea used.

> ?
> Solution : Emaitza

Already ok.

> ?
> 
> Which is it context? 
> 
> If it???s a verb, then
>   Listing : Zerrendatzea
> 
> if a noun, it could be a entry for list
> 
>   Listing : Sarrera
> 
> If it is a synonym for list, then
>  
>   Listing : Zerrenda

It is noun for source code "listing" you get via Insert->Program Listing
and currently you use Zerrenda.
What is the correct translation here?

> ?
> 
> H???. is this a plural for list entries?
> 
>   Listings :  Sarrerak
> 
> ?
> 
> If next means list of entries:
>  
>   List of Listings : Sarreren zerrenda
> 
> Otherwise, for list of lists:
> 
>   List of Listings : Zerrenden zerrenda

"Listings" and "List of Listings" should lead to the same translation
(we need to use these two terms because different LaTeX classes named
it differently, but the meaning is really the same - list of all insets
with source code you have in the document.
Currently you use Zerrendak and Zerrenden zerrenda, my guess is that
both should be Zerrenden zerrenda.

> ?
> 
> 
>see equation[[nomencl]] : ikus ekuazioa[[nomenklatura]]
> 
> As you can find at eu.po, basque translations contains [[]] 
> translated too. What is [[xxx]] for?

That is mistake, you should not use '[[..]]' anywhere in your .po translations.
'[[..]]' is just hint in what context the translated item appears.
So in your case it should look like:
msgid "see equation[[nomencl]]"
msgstr "ikus ekuazioa"

Most likely you used '[[..]]' in other translations as well and they should be
deleted...

> Can you escalate them to proper file? ;-)

They all should go just to eu.po.

You might benefit from reading README.localization in your tree or here:
http://git.lyx.org/?p=lyx.git;a=blob;f=README.localization;h=6b0b540b5eb0ebc309dc9d7ee51b75da3c9f96f9;hb=HEAD

[[]] issue is explained in part I, section 4; layouttranslations is
explained in part II.

Thanks for your contribution :)
Pavel

Re: Staging Branches

[Pavel Sanda]

Richard Heck wrote:
> If we don't need to do anything
> super-fast, then I'll just merge 2.3.2-staging into 2.3.1-staging.

I see, sounds good. Pavel