Re: Questions for Uwe once you are back

[Stephan Witt]

Am 15.01.2016 um 14:41 schrieb Peter Kümmel :
> 
> Am 14.01.2016 um 23:32 schrieb Uwe Stöhr:
>> Am 14.01.2016 um 21:22 schrieb Georg Baum:
>> 
 So I still think that creating a new git branch and copying the files
 from the tar there is the quickest and also safest way - no need to
 fiddle around with any path.
>>> 
>>> Here I strongly disagree. By doing this, you have no control over the
>>> information from the previous builds that is in the cmake cache.
>>> Therefore it is never sure whether such a build is reproducible (e.g. if
>>> you re-used the directory to build from git again).
>> 
>> I don't understand. It is up to me to decide which branch becomes
>> active. All other branches and their files are invisible for the
>> compiler and also for CMake. As I understood it CMake is only necessary
>> to tell the compiler where and in which order to take the files from. I
>> built this way now for about 2 years. Why do I need to take care of the
>> CMake cache? From where do you know that building from a git folder is
>> not reproducible? If that would be the case how can people work with git
>> in their jobs?
> 
> I also don't see a problem to build from a clean git repository.
> Only thing I would ensure is to "sit" on tagged release.

Sorry, I sent it too early…

I think there is some misunderstanding here. You’re not talking of the
same use pattern of git.

I think it should go like this:

The git-repository checkout is the source directory.
The build directory should always be outside the source directory.
A clean build starts with removing the build directory completely.

To automate builds and or make builds reproducible the use of build scripts
is good practice. There the build directory cleanup and passing of locally
adapted parameter values can be placed.

To make a release build you start from the tar-ball instead of the 
git-checkout as source directory. The rest is the same. The build
process is only different in the location of the source directory.

Stephan

> 
>> 
>>> IMO, we should not release any binary that was built in this way.
>> 
>> I don't like your 100% "basta" statements. Building under Win is
>> obviously a bit different than on Unix. Have you ever tried TortoiseGit
>> or another Git client under Windows?
>> 
>>> Instead we should find a different solution which ensures a 100%
>>> reproducible build, like we do have for all other platforms.
>> 
>> How do you control the people? Why do you think I don't care to get a
>> correct build? When I make a mistake there I will be flooded by user
>> complaints.
>> 
>> regards Uwe

Re: Questions for Uwe once you are back

[Peter Kümmel]

Am 15.01.2016 um 15:01 schrieb Stephan Witt:

Am 15.01.2016 um 14:41 schrieb Peter Kümmel :


Am 14.01.2016 um 23:32 schrieb Uwe Stöhr:

Am 14.01.2016 um 21:22 schrieb Georg Baum:


So I still think that creating a new git branch and copying the files
from the tar there is the quickest and also safest way - no need to
fiddle around with any path.


Here I strongly disagree. By doing this, you have no control over the
information from the previous builds that is in the cmake cache.
Therefore it is never sure whether such a build is reproducible (e.g. if
you re-used the directory to build from git again).


I don't understand. It is up to me to decide which branch becomes
active. All other branches and their files are invisible for the
compiler and also for CMake. As I understood it CMake is only necessary
to tell the compiler where and in which order to take the files from. I
built this way now for about 2 years. Why do I need to take care of the
CMake cache? From where do you know that building from a git folder is
not reproducible? If that would be the case how can people work with git
in their jobs?


I also don't see a problem to build from a clean git repository.
Only thing I would ensure is to "sit" on tagged release.


Sorry, I sent it too early…

I think there is some misunderstanding here. You’re not talking of the
same use pattern of git.

I think it should go like this:

The git-repository checkout is the source directory.
The build directory should always be outside the source directory.
A clean build starts with removing the build directory completely.


Sure, the git tree should not be touched, and the build should be in an
build directory; I never tough some does in-source builds.



To automate builds and or make builds reproducible the use of build scripts
is good practice. There the build directory cleanup and passing of locally
adapted parameter values can be placed.

To make a release build you start from the tar-ball instead of the
git-checkout as source directory. The rest is the same. The build
process is only different in the location of the source directory.

Stephan






IMO, we should not release any binary that was built in this way.


I don't like your 100% "basta" statements. Building under Win is
obviously a bit different than on Unix. Have you ever tried TortoiseGit
or another Git client under Windows?


Instead we should find a different solution which ensures a 100%
reproducible build, like we do have for all other platforms.


How do you control the people? Why do you think I don't care to get a
correct build? When I make a mistake there I will be flooded by user
complaints.

regards Uwe

Re: Questions for Uwe once you are back

[Stephan Witt]

Am 15.01.2016 um 14:41 schrieb Peter Kümmel :
> 
> 
> 
> Am 14.01.2016 um 23:32 schrieb Uwe Stöhr:
>> Am 14.01.2016 um 21:22 schrieb Georg Baum:
>> 
 So I still think that creating a new git branch and copying the files
 from the tar there is the quickest and also safest way - no need to
 fiddle around with any path.
>>> 
>>> Here I strongly disagree. By doing this, you have no control over the
>>> information from the previous builds that is in the cmake cache.
>>> Therefore it is never sure whether such a build is reproducible (e.g. if
>>> you re-used the directory to build from git again).
>> 
>> I don't understand. It is up to me to decide which branch becomes
>> active. All other branches and their files are invisible for the
>> compiler and also for CMake. As I understood it CMake is only necessary
>> to tell the compiler where and in which order to take the files from. I
>> built this way now for about 2 years. Why do I need to take care of the
>> CMake cache? From where do you know that building from a git folder is
>> not reproducible? If that would be the case how can people work with git
>> in their jobs?
> 
> I also don't see a problem to build from a clean git repository.
> Only thing I would ensure is to "sit" on tagged release.

I think there is some misunderstanding here. You’re not talking of the
same use pattern of git.

I think it should go like this:

The git-repository checkout is the source directory.
The build directory should always be outside the source directory.
A clean build starts with removing the build directory completely.

To automate builds and or make builds reproducible the use of build scripts
is good practice. There the build directory cleanup and passing of locally
adapted parameter values can be placed.

My 2 cents.

Stephan

> 
>> 
>>> IMO, we should not release any binary that was built in this way.
>> 
>> I don't like your 100% "basta" statements. Building under Win is
>> obviously a bit different than on Unix. Have you ever tried TortoiseGit
>> or another Git client under Windows?
>> 
>> > Instead we should find a different solution which ensures a 100%
>> > reproducible build, like we do have for all other platforms.
>> 
>> How do you control the people? Why do you think I don't care to get a
>> correct build? When I make a mistake there I will be flooded by user
>> complaints.
>> 
>> regards Uwe

Re: Questions for Uwe once you are back

[Peter Kümmel]

Am 14.01.2016 um 23:32 schrieb Uwe Stöhr:

Am 14.01.2016 um 21:22 schrieb Georg Baum:


So I still think that creating a new git branch and copying the files
from the tar there is the quickest and also safest way - no need to
fiddle around with any path.


Here I strongly disagree. By doing this, you have no control over the
information from the previous builds that is in the cmake cache.
Therefore it is never sure whether such a build is reproducible (e.g. if
you re-used the directory to build from git again).


I don't understand. It is up to me to decide which branch becomes
active. All other branches and their files are invisible for the
compiler and also for CMake. As I understood it CMake is only necessary
to tell the compiler where and in which order to take the files from. I
built this way now for about 2 years. Why do I need to take care of the
CMake cache? From where do you know that building from a git folder is
not reproducible? If that would be the case how can people work with git
in their jobs?


I also don't see a problem to build from a clean git repository.
Only thing I would ensure is to "sit" on tagged release.




IMO, we should not release any binary that was built in this way.


I don't like your 100% "basta" statements. Building under Win is
obviously a bit different than on Unix. Have you ever tried TortoiseGit
or another Git client under Windows?

 > Instead we should find a different solution which ensures a 100%
 > reproducible build, like we do have for all other platforms.

How do you control the people? Why do you think I don't care to get a
correct build? When I make a mistake there I will be flooded by user
complaints.

regards Uwe

Re: Questions for Uwe once you are back

[Stephan Witt]

> Am 15.01.2016 um 15:48 schrieb Peter Kümmel :
> 
> 
> 
> Am 15.01.2016 um 15:01 schrieb Stephan Witt:
>> Am 15.01.2016 um 14:41 schrieb Peter Kümmel :
>>> 
>>> Am 14.01.2016 um 23:32 schrieb Uwe Stöhr:
 Am 14.01.2016 um 21:22 schrieb Georg Baum:
 
>> So I still think that creating a new git branch and copying the files
>> from the tar there is the quickest and also safest way - no need to
>> fiddle around with any path.
> 
> Here I strongly disagree. By doing this, you have no control over the
> information from the previous builds that is in the cmake cache.
> Therefore it is never sure whether such a build is reproducible (e.g. if
> you re-used the directory to build from git again).
 
 I don't understand. It is up to me to decide which branch becomes
 active. All other branches and their files are invisible for the
 compiler and also for CMake. As I understood it CMake is only necessary
 to tell the compiler where and in which order to take the files from. I
 built this way now for about 2 years. Why do I need to take care of the
 CMake cache? From where do you know that building from a git folder is
 not reproducible? If that would be the case how can people work with git
 in their jobs?
>>> 
>>> I also don't see a problem to build from a clean git repository.
>>> Only thing I would ensure is to "sit" on tagged release.
>> 
>> Sorry, I sent it too early…
>> 
>> I think there is some misunderstanding here. You’re not talking of the
>> same use pattern of git.
>> 
>> I think it should go like this:
>> 
>> The git-repository checkout is the source directory.
>> The build directory should always be outside the source directory.
>> A clean build starts with removing the build directory completely.
> 
> Sure, the git tree should not be touched, and the build should be in an
> build directory; I never tough some does in-source builds.

Touching the git tree was the start of the discussion. See above.

Stephan

Re: FreeMono

[Scott Kostyshak]

On Fri, Jan 15, 2016 at 07:40:35AM +, Guenter Milde wrote:

> >> Things to improve in this context are
> 
> >> * LyX runs XeTeX five times until realizing that there is a missing font.
> >>   (Error detection should improve)
> 
> Shall I file a bug report?

We compile the document as best as possible (and thus multiple runs)
even if there is an error. The reason for this is that we still produce
a PDF and the user can access it with the "Show Output Anyway" button.
So I believe this is expected behavior.

It might be a valid enhancement request to ask LyX to fail as soon as
possible. I would be in favor of this. I wonder what others think.

Scott


signature.asc
Description: PGP signature

Re: beta release

[Scott Kostyshak]

On Sun, Jan 10, 2016 at 08:12:54PM +0100, Georg Baum wrote:
> Scott Kostyshak wrote:
> 
> > Does any one view an issue as a beta blocker?
> 
> The current situation regarding \output_changes is not good, so I would see 
> http://www.lyx.org/trac/ticket/9841 as a beta blocker.
> 
> Fortunately Guillaume implemented a proper solution, so the only thing which 
> is needed is that other people who participated in the original discussion 
> (especially Pavel) tell whether the patch does indeed implement the solution 
> that we agreed at.

Georg can you confirm that 5c2d0499 (and the amendment at 9267b2b2) is
all we need to do for 2.2.0 regarding #9841?

Scott


signature.asc
Description: PGP signature

Re: [LyX/master] Update LFUNs.lyx to current format

[Guillaume Munch]

Le 15/01/2016 20:32, Georg Baum a écrit :

commit 4c3b8bf7c7205e26b28b6562be11105558ec3250
Author: Georg Baum 
Date:   Fri Jan 15 21:31:57 2016 +0100

 Update LFUNs.lyx to current format

diff --git a/development/tools/gen_lfuns.py b/development/tools/gen_lfuns.py
index 8e4bc88..0fb9380 100755
--- a/development/tools/gen_lfuns.py
+++ b/development/tools/gen_lfuns.py
@@ -43,9 +43,10 @@ ID_DICT = dict(name=LFUN_NAME_ID, action=LFUN_ACTION_ID, 
notion=LFUN_NOTION_ID,
  syntax=LFUN_SYNTAX_ID, params=LFUN_PARAMS_ID, 
sample=LFUN_SAMPLE_ID, origin=LFUN_ORIGIN_ID)

  LFUNS_HEADER = """# gen_lfuns.py generated this file. For more info see 
http://www.lyx.org/
-\\lyxformat 503
+\\lyxformat 504
  \\begin_document
  \\begin_header
+\\save_transient_properties true
  \\origin /systemlyxdir/doc/
  \\textclass article
  \\begin_preamble



Is a step in Development.lyx missing?

Re: "Splitting of consecutive environments has been reworked and enhanced"

[Guillaume Munch]

Le 14/01/2016 20:13, Enrico Forestieri a écrit :

On Thu, Jan 14, 2016 at 03:59:41PM +, Guillaume Munch wrote:


We might be speaking of two different issues:

* If I click on the right-hand half of the separator, the cursor moves
after the separator both visually and logically (a position that cannot
be reached using ← and →).

* If I click further on the line to the right of the separator (does not
need to be too far away), then the cursor gets located visually to the
left and logically to the right (what could be reached using ↑ and ↓
until your patch).

To see if the cursor is logically to the left or the right of the
separator, I try to see which of Del of Backspace deletes it.


I have now found where to tweak the sources and the attached x1.diff
patch solves the issue for me.


Thanks again for taking all these remarks into account.

x1.diff works as expected, it solves both issues, and I am ready to +1 you.

However, this reveals new ways of creating an "after" cursor position:

* A visually-after cursor position appears with Ctrl+Shift+Arrows 
(LFUN_*_SELECT_WORD of something like this). It remains a right position 
after deselection, for instance by doing copy and immediately paste.


* A logically-after cursor position appears when double clicking the 
separator inset or the line.






A second issue I just noticed is when deleting the separator: the
paragraph after should not immediately be merged with the one that
contains the deleted separator, if none is empty, I think. Hitting Del
should just remove the separator. (To test this, start with two
non-empty enumerate environments with a par break separator at the end
of the first one, and then try to delete the separator.)


I will have a look at this.


The attached x2.diff patch takes care of this. It seems that this
behavior was a deliberate choice of mine, but it was wrong, apparently.



Actually I think it was a good idea, but only when the separator is 
alone on the line. Would you like to keep your code but add instead a 
check for the separator being alone on its paragraph? Otherwise I can 
vouch for the patch, if you prefer removing your code.






If you think that hitting enter should introduce a plain separator
instead of a parbreak one, this would be accomplished in the sources
with a really trivial change. I choose a parbreak simply because it
is completely equivalent to the old Separator layout.
However, note that when importing old documents, the old Separator
layout has still to be converted to a parbreak separator, otherwise
the output might be changed.



I did not think of it this way but, yes, this would be a convenient
solution. The main advantage, I find, is the overall consistency in
the chosen solution, in particular with Alt+M P.


This would be accomplished by the attached patch.



Indeed the patch is trivial and I can vouch for it (if needed
symbolically). Please commit it if you are convinced as well that this
is a good solution.


I took this as a +1 and committed the patch.


Thanks.


Guillaume

Re: beta release

[Georg Baum]

Scott Kostyshak wrote:

> Georg can you confirm that 5c2d0499 (and the amendment at 9267b2b2) is
> all we need to do for 2.2.0 regarding #9841?

Yes, this is fine now.

I did also update the docs regarding the swapped \output_changes position 
using the experimental mode of updatedocs.py which works fine btw.


Georg

Re: [LyX/master] Update LFUNs.lyx to current format

[Georg Baum]

Guillaume Munch wrote:

> Is a step in Development.lyx missing?

IIRC we did not decide that yet. IMHO it is not required to update these 
files for each format change, but some time ago we decided that for a 
release all files should be up to date, and it is in the release checklist.


Georg

Re: Questions for Uwe once you are back

[Georg Baum]

Peter Kümmel wrote:

> I also don't see a problem to build from a clean git repository.
> Only thing I would ensure is to "sit" on tagged release.

I agree that building from a clean git directory is not a problem concerning 
the resulting build or reproducibility.

There is however one difference between building from a git tag and from the 
corresponding source tar ball (which is not the main topic of this thread): 
If you build from git you do not check that the tar ball is complete. In 
theory, completeness of the tar ball is checked by "make distcheck", but it 
does not take files into account that are only needed for windows (e.g. it 
would not find whether a file from 3rdparty is missing).


Georg

Re: [LyX/master] Update LFUNs.lyx to current format

[Guillaume Munch]

Le 15/01/2016 20:50, Georg Baum a écrit :

Guillaume Munch wrote:


Is a step in Development.lyx missing?


IIRC we did not decide that yet. IMHO it is not required to update these
files for each format change, but some time ago we decided that for a
release all files should be up to date, and it is in the release checklist.



I believe as well that we should not extend the already long checklist 
for format changes. Updatedocs could take care of running gen_lfuns and 
then update it to the latest format.

Re: Questions for Uwe once you are back

[Georg Baum]

Am 14.01.2016 um 23:32 schrieb Uwe Stöhr:

Am 14.01.2016 um 21:22 schrieb Georg Baum:


So I still think that creating a new git branch and copying the files
from the tar there is the quickest and also safest way - no need to
fiddle around with any path.


Here I strongly disagree. By doing this, you have no control over the
information from the previous builds that is in the cmake cache.
Therefore it is never sure whether such a build is reproducible (e.g. if
you re-used the directory to build from git again).


I don't understand. It is up to me to decide which branch becomes 
active. All other branches and their files are invisible for the 
compiler and also for CMake. As I understood it CMake is only 
necessary to tell the compiler where and in which order to take the 
files from.
Indirectly (via the MSVC project files .sln and .vcxproj) yes. In order 
to do so, cmake does run lots of tests. These tests are partly 
implemented in the cmake installation, and partly in the LyX sources 
(development/cmake). The results of these tests are cached. If you now 
re-use an existing cmake cache to build LyX from different sources, then 
the contents of the MSVC project files (and therefore the resulting 
build) depends on the history of your previous cmake calls, and whether 
something was changed in development/cmake in the meantime. If you 
ensure that no cached information is re-used then the build is 
reprodcible (but you would need to specify the 40 paths again withj your 
current way of calling cmake).


I built this way now for about 2 years. Why do I need to take care of 
the CMake cache? From where do you know that building from a git 
folder is not reproducible?


I did not say that. Building from a git folder is reproducible if you do 
it correctly (i.e. deleting all cached information from a previous run).



If that would be the case how can people work with git in their jobs?


Almost all people who work with git (or any other version control 
system) on their jobs do have an automated nightly build which does not 
need any manual input, and is completely configured by configuration 
files, batch files or similar mechanisms. If they don't, they will run 
sooner or later into problems (I once knew a software company which did 
not have such a build. The company does not exist anymore).



IMO, we should not release any binary that was built in this way.


I don't like your 100% "basta" statements. Building under Win is 
obviously a bit different than on Unix. Have you ever tried 
TortoiseGit or another Git client under Windows?


No. And I don't need to (but I have lots of experience with building 
software under windows). The problem we are discussing has nothing to do 
with git. It has something to do with calling cmake in such a way that 
the build works, and without the need for manually specifying 40 paths.



> Instead we should find a different solution which ensures a 100%
> reproducible build, like we do have for all other platforms.

How do you control the people? Why do you think I don't care to get a 
correct build? When I make a mistake there I will be flooded by user 
complaints.


Please do not put words in my mouth that I did not say. I explained why 
I think that a different solution to the problem of manually specifying 
40 paths for building each new release than the one you choose is 
needed. I did not say that you don't care to get a correct build. I 
rather think that you overestimate the work which is needed to follow my 
proposal, and that you underestimate the problems that can arise from 
the current way of building. This is not equal to not caring.


And these problems do exist. The 2.2 alpha is not the first windows 
binary that turned out to be built from different sources than 
originally thought (http://www.lyx.org/trac/ticket/9878). I remember a 
similar issue from several years ago, might be 1.6 or 2.0. This type of 
mistakes (which can cost lots of hours or even days of wasted time for 
several people) is easy to make with your current approach. It is very 
difficult to make with my proposal.


I am willing to help you to get a reproducible, clean build. I am not 
willing to waste my time investigating bugs that are caused by 
inconsistently built binaries.



Georg

Re: Windows: release with Qt 5.5.1 or 5.6?

[Uwe Stöhr]

Am 15.01.2016 um 03:39 schrieb Scott Kostyshak:


Give me another day to test but I think that I am basically ready for beta1.


Sounds good to me.


I tested it a lot today on different PCs and from my point of view it is 
stable. So I am ready for beta1.


regards Uwe

Re: FreeMono

[Kornel Benko]

Am Freitag, 15. Januar 2016 um 07:40:35, schrieb Guenter Milde 

> On 2016-01-14, Kornel Benko wrote:
> > Am 14. Januar 2016 um 12:28:51, schrieb Guenter Milde 
> >> On 2016-01-14, Kornel Benko wrote:
> 
> Dear Kornel,
> 
> >> (BTW: in the Document>Settings>Fonts GUI, I can see FreeSerif and
> >> FreeSans, but not FreeMono (instead there is FreeCourier) despite
> >> FreeMono beeing installed at the system.)
> 
> This is now solved: I locally deactivated a number of auto-installed
> fonts that I don't use - including FreeMono.

I suppose it means you have now FreeMono?

> > Interestingly, I searched for FreeCourier, but could not find the font.
> > I found only https://www.gnu.org/software/freefont/, which does not use
> > the name FreeCourier. So, where do you have it from?
> 
> It is from the Debian package "t1-cyrillic" (Free Times, Free
> Helvetian, Free Courier, Free Avant Garde, Free Paladin, Free Schoolbook,
> Free Bookman und Free Chancery).
> https://packages.debian.org/source/stretch/scalable-cyrfonts

I see.

> ...
> 
> 
> >> Things to improve in this context are
> 
> >> * LyX runs XeTeX five times until realizing that there is a missing font.
> >>   (Error detection should improve)
> 
> Shall I file a bug report?
> 
> 
> >> * ctest tests do not report or store the logs for failed tests.
> 
> > It is lyx calling xelatex from temporary directory. This directory is
> > deleted after lyx completes. No way to retrieve the logs.
> 
> In the GUI, we now even have a "go to temp dir" button in the log window ...
> 
> For command line export, I suggest a new option --keep-temporary-dir
> that would do exactly this and print the name of the temp dir to stdout:
> 
>   temporary files in /

For testing purposes is maybe better if the selection could be done at command 
line too.
For instance:
--temporary-dir _temp_dir_existing_path_

> Enhancement report?
> 
 +1

> Thanks,
> Günter

Kornel

signature.asc
Description: This is a digitally signed message part.