Re: [LyX/master] Autotools: restore deprecation warning

Stephan Witt wrote: > Yes. The problem is trying to create an empty archive, IMO. Indeed. On linuyx ar does not complain about that, so I did not notice. I moved the disabling of the build one directory up, please try whether it works now. Georg

Re: [LyX/master] Autotools: restore deprecation warning

Jean-Marc Lasgouttes wrote: > Le 09/06/2016 à 22:32, Georg Baum a écrit : >> Jean-Marc Lasgouttes wrote: >> >>> Le 09/06/16 à 20:47, Georg Baum a écrit : >>>> >>>> This causes a warning in boost: >>>> >>>> ../../../3rdpart

Re: [LyX/master] Autotools: restore deprecation warning

Stephan Witt wrote: > Is this work in progress? Currently after this change I cannot build LyX > anymore an Mac with autotools. The build error is shown below. No, this is not work in progress (at least it was not supposed to be). Did you rerun autogen.sh and configure? If your compiler is

Re: CMake + clang failure

Guillaume Munch wrote: > Le 11/06/2016 03:00, Scott Kostyshak a écrit : >> -- Using GCC version 4.2.1 >> CMake Error at CMakeLists.txt:267 (message): >>gcc >= 4.3 is required. > > From INSTALL: > >First of all, you will need a recent C++ compiler, where recent means >that the

Re: [LyX/master] Autotools: restore deprecation warning

Jean-Marc Lasgouttes wrote: > Le 09/06/16 à 20:47, Georg Baum a écrit : >> >> This causes a warning in boost: >> >> ../../../3rdparty/boost/libs/signals/src/signal_base.cpp:136:37: warning: >> ‘auto_ptr’ is deprecated (declared at >> /usr/include/c++/4.9/ba

Re: [LyX/master] Autotools: restore deprecation warning

Guillaume Munch wrote: > commit a73f2e6eb6f0a7999d6b90d3c62552e4fbe3b66e > Author: Guillaume Munch > Date: Thu Jun 2 18:00:22 2016 +0100 > > Autotools: restore deprecation warning > > -Wno-deprecated-declarations was added at 314a121c. This causes a warning in

Re: Tarballs for LyX 2.2.0 are on FTP

Guillaume Munch wrote: > Le 07/06/2016 00:00, Richard Heck a écrit : >> >> Our use of git would make it very easy for us to have a branch in which >> new features not requiring format changes could also be put. >> > > This solution would be fine by me too, if people agree to have three >

Re: [LyX/master] Require a C++11 compiler

Scott Kostyshak wrote: > Ah yes that is more important. I'm still wondering if it should go in > RELEASE-NOTES as well. In our ANNOUNCE we recommend that packagers read > the RELEASE-NOTES file. Don't we want packagers to be aware of this > significant change? Or do we just assume they'll read

Re: [LyX/2.2.x] Fix some problems with the preamble in th eKoma-script letter template.

Richard Heck wrote: > diff --git a/lib/templates/koma-letter2.lyx > b/lib/templates/koma-letter2.lyx index 43cbdb0..7251ff3 100644 > --- a/lib/templates/koma-letter2.lyx > +++ b/lib/templates/koma-letter2.lyx > @@ -1,5 +1,5 @@ > #LyX 2.2 created this file. For more info see http://www.lyx.org/ >

Re: [LyX/master] Remove unneeded files from extract.sh

Jean-Marc Lasgouttes wrote: > Sure, but we have 4.3M in typeof/, which is only required because the > bcopy decided that we needed the whole directory bbecause we use the > whole function directory. I removed it. If we know that it is not needed it is one line in extract.sh:-) > Actually, it

Re: boost:regex & gcc

Pavel Sanda wrote: > Guillaume Munch wrote: >> Any reason to want to get rid of boost completely? > > Well, that's a long term wish. It is not nice to pack boost lib together > with our sources and someone need to care updating boost within the source > tree. Updating is simple. It took me half

Re: [PATCH] unique_ptr and some clean-up

Jean-Marc Lasgouttes wrote: > Le 06/06/2016 22:26, Georg Baum a écrit : > > Why do you remove the code that checks for C++11? At some time my idea > was to do > > for arg in "" "-std c++11" "-std c++0x" ; do >if $CXX $arg is a C++11 compil

Re: [PATCH] unique_ptr and some clean-up

Guillaume Munch wrote: > Le 05/06/2016 12:54, Georg Baum a écrit : >> Therefore I would vote to support MSVC 2013 and later, but nothing >> earlier. > > In light of the lack of support of unicode string literals in MSVC 2013, > the availability of mingw and the fact t

Re: Tarballs for LyX 2.2.0 are on FTP

Jean-Marc Lasgouttes wrote: > Le 05/06/2016 à 21:05, Guillaume Munch a écrit : >> Yet, most of the file format changes are very simple. I wonder whether >> one could introduce a single compilation variable to disable them, >> and ask developers to enclose file-format-specific code between the >>

Re: Tarballs for LyX 2.2.0 are on FTP

Liviu Andronic wrote: > We already have nightly builds for Ubuntu Linux: > https://launchpad.net/~lyx-devel/+archive/ubuntu/daily > > It's been running for couple of years (probably all through the 2.2 > development cycle), though I'm not sure it's made much of an impact in > terms of testing

Re: Tarballs for LyX 2.2.0 are on FTP

Sorry for the late reply, I somehow missed this message. Jean-Marc Lasgouttes wrote: > Le 31/05/2016 à 22:26, Georg Baum a écrit : >> We need to decide: Either have a fixed schedule, and an unknown feature >> set of the next release, or a fixed feature set, and an unknown sch

Re: One official build system?

Kornel Benko wrote: > Am Sonntag, 5. Juni 2016 um 20:34:38, schrieb Liviu Andronic > >> On Sun, Jun 5, 2016 at 7:43 PM, Kornel Benko wrote: > > Unfortunately cmake is not able yet to produce more than one debian > package. Recently started discussions to

Re: One official build system?

Scott Kostyshak wrote: > On Sun, Jun 05, 2016 at 01:59:53PM +0200, Kornel Benko wrote: >> >> OK, starting on the list first. I can only comment on the cmake part. >> >> [A] detection of external dependencies >> cmake does full detection IMHO >> [B] create .rpm >> cmake creates rpm, deb, >>

Re: One official build system?

Kornel Benko wrote: > Don't know if this helps, but I never use relative path with cmake. > #mkdir some_build_path > # cd some_build_path > # cmake abs_path_to_lyx_sources ... I use relative paths, and it works fine. Georg

Re: One official build system?

Kornel Benko wrote: > Am Sonntag, 5. Juni 2016 um 19:03:51, schrieb Kornel Benko > <kor...@lyx.org> >> Am Sonntag, 5. Juni 2016 um 18:43:03, schrieb Georg Baum >> <georg.b...@post.rwth-aachen.de> >> > Kornel Benko wrote: >> > > ... >&g

Re: One official build system?

Kornel Benko wrote: > Version suffix for bin and locales is already used as expected. Very good. > I think, there is nothing to do for windows yet, because it uses already > cmake. OK (I was not sure whether the changes for linux would imply changews for windows as well). Georg

Re: mingw not compilable ATM

Kornel Benko wrote: > Trying to compile with 'development/cmake/scripts/xmingw' I get > ... > [ 24%] Building CXX object > [ src/frontends/qt4/CMakeFiles/frontend_qt.dir/_allinone_const.C.obj > cd /usr/BUILD/mingw/src/frontends/qt4 && /usr/bin/i686-w64-mingw32-g++ >

Re: One official build system?

Kornel Benko wrote: > ATM cmake installs almost everything under the installation directory. > Exceptions are (defaults for versioned) > manuals /usr/local/man, (e.g. /usr/local/man/man1/man1/lyxclient2.3.1) > lyx-icon /usr/local/share/icons/hicolor/scalable/apps/lyx2.3.svg > desktop

Re: One official build system?

Kornel Benko wrote: > OK, starting on the list first. I can only comment on the cmake part. > > [A] detection of external dependencies > cmake does full detection IMHO > [B] create .rpm > cmake creates rpm, deb, > [E] create window package > don't know, we should ask Peter > [I] Reliability >

Re: [LyX/master] Implement gcc version check for cmake

Kornel Benko wrote: > Am Sonntag, 5. Juni 2016 um 15:54:43, schrieb Georg Baum <b...@lyx.org> >> commit c2433d8b8f2bd7be363ddc96bcb95116ac5ea8cd >> Author: Georg Baum <b...@lyx.org> >> Date: Sun Jun 5 15:54:29 2016 +0200 >> >> Implement

Re: [PATCH] unique_ptr and some clean-up

Guillaume Munch wrote: > Dear List, > > > I have recently started using c++11 features, and, one thing leading to > another, some cleaning of the tree happened. Apparently most of the > changes below are supported by old compilers (exceptions below), i.e. > MSVC 2012 and maybe MSVC 2010 (if

Re: One official build system?

Kornel Benko wrote: > Am Samstag, 4. Juni 2016 um 09:55:10, schrieb Georg Baum >> >> However, this is not so important. With autotools we have only very few >> people who understand the macro stuff in m4/, config/ and configure.ac, >> but everybody is able to do his m

Re: One official build system?

Scott Kostyshak wrote: > On Sat, Jun 04, 2016 at 07:55:28PM +0200, Stephan Witt wrote: >> >> > Am 04.06.2016 um 10:15 schrieb Liviu Andronic : >> > >> > If moving to cmake definitively would imply losing version suffix >> > functionality, this would be a big issue for my

Re: [LyX/master] Get rid of pseudo diffs when remerging strings

Georg Baum wrote: > commit 960bcc71c18b21e0444cfce3d9a5e7c10cb3172a > Author: Georg Baum <b...@lyx.org> > Date: Sat Jun 4 17:33:19 2016 +0200 > > Get rid of pseudo diffs when remerging strings > > cmake sorts the input files for lyx_pot.py internal

Re: [LyX/master] Get rid of pseudo diffs when remerging strings

Richard Heck wrote: > OK, please commit to 2.2.x. (Safe enough, yes?) Done. Yes, it is safe. And even if something went wrong you would now see it in the diffs when sommitting .po files: The only visible diffs should now be changed line numbers in source files, and of course added, changed or

Re: One official build system?

Abdelrazak Younes wrote: > Hi Guys, > > Funny to discover that the same discussion is coming back every couple > of years :-) I am not surprised at all, maintaining two build systems with such a small amount of developers is simply stupid. > I think the only point to discuss is the GLOB

Re: One official build system?

Richard Heck wrote: > On 06/03/2016 04:28 PM, Scott Kostyshak wrote: >> On Fri, Jun 03, 2016 at 09:38:09PM +0200, Kornel Benko wrote: >>> Am Freitag, 3. Juni 2016 um 12:42:33, schrieb Richard Heck >>> I guess maybe there is a question worth discussing here about how many

Re: SVG display on LyX appears corrupted on the 2.2RC1 Windows build

Guillaume Munch wrote: > Do you want to commit? Thanks for the reminder, it is in now at 6bd5263405340b. Georg

Re: [LyX/master] Do not duplicate jpg format

Guillaume Munch wrote: > Why not just using a set instead of a vector if this is important? I believe that the order matters. We prefer the first format that is reachable with a converter. With the current solution, qt can give a preference, if we used a set then we would prefer the first in

Re: [PATCH] microtype

Pavel Sanda wrote: > Georg Baum wrote: >> > I just blindly copied what was there for other on-off packages, because >> > I have little clue what tex2lyx code does and zero comments in critical >> > sections does not help. I know it's not your fault ;) >

Re: [PATCH] microtype

Pavel Sanda wrote: > I just blindly copied what was there for other on-off packages, because > I have little clue what tex2lyx code does and zero comments in critical > sections does not help. I know it's not your fault ;) Actually the other packages are not on-off, they are off-auto-on. This is

Re: [PATCH] microtype

Pavel Sanda wrote: > Pavel Sanda wrote: >> @@ -813,7 +814,7 @@ void Preamble::handle_package(Parser , string const >> & name, >> else if (name == "amsmath" || name == "amssymb" || name == "cancel" || >> name == "esint" || name == "mhchem" || name == "mathdots" || >> name == "mathtools" || name

Re: [LyX/2.1.x] Update lyx2lyx from 2.2.0. This is in preparation for the 2.1.5 release.

Richard Heck wrote: > commit 4eb3ed96e53ab0eb2af519caa6125cac79c823ad > Author: Richard Heck > Date: Wed Jun 1 12:31:48 2016 -0400 > > Update lyx2lyx from 2.2.0. This is in preparation for the 2.1.5 > release. > > diff --git a/lib/lyx2lyx/LyX.py b/lib/lyx2lyx/LyX.py >

Re: Tarballs for LyX 2.2.0 are on FTP

Guillaume Munch wrote: > Le 26/05/2016 07:45, Jean-Marc Lasgouttes a écrit : > >> Time to think about the release date of 2.3.0 now ;) >> > > Yes, let's have this discussion :) > > I find the interval between feature releases too high. Having an > interval longer than one year (more than two

Re: build requirements for Qt5 build

Jean-Marc Lasgouttes wrote: > Le 31/05/2016 à 13:53, Kornel Benko a écrit : >> use >> # export QT_SELECT=qt5 >> to select qt5 binaries. > > Indeed, it is much better. I'll change configure to do just that. Note that QT_SELECT needs to be defined not only when configure runs (that would be

Re: build requirements for Qt5 build

Jean-Marc Lasgouttes wrote: > Le 31/05/2016 à 11:38, Liviu Andronic a écrit : >> http://packages.ubuntu.com/search?searchon=contents=qglobal.h=exactfilename=xenial=any >> >> /usr/include/i386-linux-gnu/qt5/QtCore/qglobal.h >> /usr/include/x86_64-linux-gnu/qt5/QtCore/qglobal.h > > How do we get

Re: Tarballs for LyX 2.2.0 are on FTP

Uwe Stöhr wrote: > Am 25.05.2016 um 00:37 schrieb Richard Heck: > >> We have lots of warnings like this. They are usually fixed by doing the >> conversion explicitly, so probably nothing really needs to be done for >> the release. > > This is suspicious to me because usually MSVC has good

Re: [LyX/master] * lib/RELEASE-NOTES

Guillaume Munch wrote: > Because on the other hand with qt4 there is the critical > http://www.lyx.org/trac/ticket/9362. I also noticed that lyx is very > slow with qt4 now, with profiling showing that most of the time is spent > in QTextLine::setLineWidth() below GuiFontMetrics::breakAt(). In

Re: Tarballs for LyX 2.2.0 are on FTP

Scott Kostyshak wrote: > Hi all, > > The tarballs for LyX 2.2.0 can be found at > > ftp://ftp.lyx.org/pub/lyx/devel/lyx-2.2/lyx-2.2.0/ Builds and runs fine on debian 8.1, except when configuring with version suffix: http://www.lyx.org/trac/ticket/10159. Since this also happens with 2.1.4 it

Re: Plan to tag and tar 2.2.0rc2 on Monday

Scott Kostyshak wrote: > Dear all, > > Unless something comes up, I'm planning to tag and tar rc2 on Monday. At > that point I'll put the tar balls on the FTP and whenever Mac and Win > binaries are uploaded we will announce the release. Great! I wonder whether we need RC2 at all, or whether we

Re: [patch] fix bug 10124 (XHTML export of some symbols)

Scott Kostyshak wrote: > On Sat, May 21, 2016 at 09:56:07AM -0400, Richard Heck wrote: >> On 05/21/2016 05:11 AM, Georg Baum wrote: >> > While testing imagemagick 7 (more on that later) I stumbled upon bug >> > 10124 as well. It is a simple typo where LyX outputs / ins

LyX does work with ImageMagick 7

Hi, now I found some time to test and it turned out that some information in this thread is wrong. Therefore I removed the warning from release notes again. 1) Imagemagick 7 does still contain the 'convert' utility. If you install from source on unix, it is simply a symlink to 'magick'. If

[patch] fix bug 10124 (XHTML export of some symbols)

While testing imagemagick 7 (more on that later) I stumbled upon bug 10124 as well. It is a simple typo where LyX outputs / instead of . OK for 2.2.0? Georgdiff --git a/src/mathed/MathMacro.cpp b/src/mathed/MathMacro.cpp index e01f7c2..9fe6e15 100644 --- a/src/mathed/MathMacro.cpp +++

Re: Python 2 in release notes

José Matos wrote: > On Monday, May 9, 2016 9:46:01 PM WEST Scott Kostyshak wrote: >> Georg or José, please feel free to make changes to the RELEASE-NOTES >> regarding Python if you think it would make things more clear. >> >> Scott > > I think that Georg's formulation is clear and more correct

Re: LyX doesn't work with ImageMagick 7

Am 11.05.2016 um 23:40 schrieb Uwe Stöhr: Am 11.05.2016 um 22:11 schrieb Georg Baum: Uwe, can you please tell what "broken" means? LyXHTML still triggers the comand "convert" for the image conversions. But in IM7 there is now only the command "magick".

Re: LyX doesn't work with ImageMagick 7

Am 11.05.2016 um 15:55 schrieb Richard Heck: On 05/10/2016 06:00 PM, Uwe Stöhr wrote: Good news. IM decided now to continue the IM6 series. they just released 6.9.4: http://www.imagemagick.org/download/binaries/ So there is no to hurry with LyXHTML. It would nevertheless bee helpful if LyXHTML

Re: LyX doesn't work with ImageMagick 7

Uwe Stöhr wrote: > Am 07.05.2016 um 14:34 schrieb Uwe Stöhr: > >> Many thanks. I tested it and it works well. >> +1 to go in to master. >> >>> Imagemagick is unfortunately known for frequent security issues. IMHO >>> the fix would be safe for 2.2.0, >> >> +1 > > Scott, this issue is important

Re: .po files: Native or unix line ends?

Am 10.05.2016 um 01:50 schrieb Uwe Stöhr: Am 09.05.2016 um 21:48 schrieb Georg Baum: Therefore I asked. How do they get the .po files after a string remerge? I don't know. Maybe from git but I know also that download them via our TRAC websites. If it is the latter I fear they will get

Re: Update on situation for 2.2.0 release

Scott Kostyshak wrote: > On Sat, May 07, 2016 at 11:16:50AM +0200, Georg Baum wrote: >> >> Done. Now I would recommend to merge all .po file contributions that are >> not based on the latest remerge by >> >> python development/tools/mergepo.py -o -l xx -t po /tm

Re: [patch] simplify .pot file generation

Kornel Benko wrote: > Ah, yes. I remember trying many things to convince 'make' to be as lazy as > possible. Changing some source does not always affect the translatable > strings. So we may also stay with your suggestion. In the end, it does not > take that long. OK, I did that for consistency

Re: [LyX/master] German UserGuide.lyx: tons of typographic fixes sent in by an unknown user

Guillaume Munch wrote: > Le 09/05/2016 21:14, Georg Baum a écrit : >> This is BTW a good example why it is always useful to look at the diff >> before committing, and why having redable diffs (as currently discussed >> in the .po file thread) is important. >> >

Re: [LyX/master] German UserGuide.lyx: tons of typographic fixes sent in by an unknown user

Guillaume Munch wrote: > I think compression has been enabled by mistake. It also made git think the file is binary, therefore not applying the native line end conversion after the fix anymore. I fixed this at 38e9752c01. From now on, everything should be fine again. This is BTW a good

Re: [patch] simplify .pot file generation

Kornel Benko wrote: > Looks good. But you could omit the creation of ${_lyxname}.cat_tmp.pot, as > this was only needed to make the conversion. > > So > COMMAND ${LYX_PYTHON_EXECUTABLE} > ARGS "${TOP_CMAKE_PATH}/po/cat.py" ${_py_sources} > >

Re: 2.2-rc1 Tools->Reconfigure: "SyntaxError"

José Matos wrote: > On Thursday, May 5, 2016 2:19:32 PM WEST Georg Baum wrote: >> The former is safe and easy (see attached). I am not familiar enough with >> python3 to judge whether TeXFiles.py can be made work with python3 and >> python2 safely. >> >> G

Re: .po files: Native or unix line ends?

Am 09.05.2016 um 01:34 schrieb Uwe Stöhr: Am 08.05.2016 um 22:36 schrieb Georg Baum: 3) A translator sends a .po file with unix line ends 4) A translator sends a .po file with windows line ends The question is how can I check this? You don't need to check that, but if you want, open

.po files: Native or unix line ends?

Hi, the following is mainly for developers on windows, since others won't see any difference. .pot files are now always created with unix line ends in the latest 2.3-staging branch. This should fix the stray '\r' characters that appeared in .po files after string remerge on windows. unix

[patch] simplify .pot file generation

Kornel, while investigating the .po file line end problem I noticed that the .pot file generation with cmake does first write windows line ends and then a converter is called to create unix line ends. I would like to simplify this in 2.3-staging (see attached). OK? Georgdiff --git

Re: [LyX/2.3-staging] Ensure unix line ends for configure.ac

Kornel Benko wrote: > Sorry, I do not see how this would mix anything. > Wouldn't the line endings be corrected on commit? After commit, yes. But I want to avoid that simply running a .po update step without commit changes line endings, since this could be confusing, and git would also warn on

Re: [LyX/2.3-staging] Ensure unix line ends for configure.ac

Kornel Benko wrote: > Introducing .gitattributes makes specifying line-endings for *.po files > acceptable too IMHO. (As you already proposed at > https://www.mail-archive.com/lyx-devel@lists.lyx.org/msg193484.html) Yes, but this would only fix one part of the problem. The other one would be to

Re: Replying to [comment:6 uwestoehr]: (Ticket #10081)

racoon wrote: > On 04.05.2016 01:06, Uwe Stöhr wrote: >> Am 22.04.2016 um 16:24 schrieb racoon: >> we found out that your Windows system is heavily "fragmented". >>> >>> I am not sure whom you mean by "we" who found out that my Windoes system >>> is "heavily fragmented". Do you mean you and

Python 2 in release notes

lib/RELEASE-NOTES contains the following paragraph: * LyX needs to be run under Python 2 and will not work properly on systems where Python 3 is the default binary. See #7030 to know how to fix this properly, since simple shebang conversion in *.py files will not be enough. I believe that

Re: SVG Icon going to fallback plaintext in Windows

Shankar Giri wrote: > Bug 2: Specifically for MinGW-W64 pacman repository built Qt libs, the > pixmap.load(path); will fail for SVGs and SVGZs (built without SVG > support). So icons all go blank and instead show fall-back text. My > patch was aiming to only temporarily address Bug 2 not Bug 1.

Re: Update on situation for 2.2.0 release

Scott Kostyshak wrote: > On Thu, May 05, 2016 at 02:32:46PM +0200, Georg Baum wrote: >> >> I would like to merge all changes to mergepo.py from 2.3-staging to >> master (see attached). The users won't see this script at all, but it >> will make updating translations ea

Re: LyX doesn't work with ImageMagick 7

Uwe Stöhr wrote: > ImageMagick released the new major version 7. Unfortunately they removed > the convert executable. One has to use the command "magick" instead of > "convert". This is a good thing. The name convert is too general (and indeed, windows includes a convert.exe for converting

Re: Update on situation for 2.2.0 release

l make updating translations easier, especially since most translators work on the rc1 .po files that have been generated before the latest remerge (which caused a resorting of entries). Georg commit dae9f6a83df37576fbb3753492fe6a1094d92248 Author: Georg Baum <b...@lyx.org> Date: Sun Apr

Re: [LyX/2.3-staging] Mingw-w64 build fixes for long long

Kornel Benko wrote: > Am Donnerstag, 5. Mai 2016 um 13:38:54, schrieb Georg Baum <b...@lyx.org> >> commit 06a43e860f7a9e7e21f3d320aa2b2aed69635d38 >> Author: Georg Baum <b...@lyx.org> >> Date: Thu May 5 13:05:12 2016 +0200 >> >> Mingw-w64 buil

Re: Update on situation for 2.2.0 release

Guillaume Munch wrote: > Le 04/05/2016 21:39, Scott Kostyshak a écrit : >> >> 9. Disabled OK button in Doc Settings if negative value (allowed in >> 2.1.x). See #10095 and [3]. I posted a patch. It is just a matter of >> seeing if there is enough support for it. >> > > I thought there was

Re: 2.2-rc1 Tools->Reconfigure: "SyntaxError"

Scott Kostyshak wrote: > The problem is that the script is being called with Python3 on your > system. We either need to make sure the script is called with Python2 or > (preferably) make the script compatible with Python3. The former is safe and easy (see attached). I am not familiar enough

Re: SVG display on LyX appears corrupted on the 2.2RC1 Windows build

Guillaume Munch wrote: > Le 27/04/2016 21:42, Georg Baum a écrit : >> Guillaume Munch wrote: >> >>> Is there a criteria to detect "bad" svg converters (at least some of >>> them)? In the other message you wrote about "explicit svg->png >>&g

Re: SVG display on LyX appears corrupted on the 2.2RC1 Windows build

Guillaume Munch wrote: > Is there a criteria to detect "bad" svg converters (at least some of > them)? In the other message you wrote about "explicit svg->png > converter". What does explicit mean? explicit means "no default", e.g. either a manually defined one, or one found by confugure.py. My

Re: SVG display on LyX appears corrupted on the 2.2RC1 Windows build

Scott Kostyshak wrote: > Even in the case where imagemagick could produce low quality results, if > imagemagick is used for the conversion for the PDF wouldn't it make > sense to also use it for LyX's display? This would give the user a > better chance of realizing that the final output is poor

Re: SVG display on LyX appears corrupted on the 2.2RC1 Windows build

Guillaume Munch wrote: > Your last iteration of the patch looks ok to me. Let's just ask Georg if > this is what he had in mind in his comment at #9778. You mean the one from April 18? Yes, this is what I had in mind. The only question I'd have (at this point of the release phase) is whether

Re: Blanket permission

Shankar Giri Venkita Giri wrote: > As requested, here is the permission. > > > > I hereby grant permission to licence my contributions to LyX under > the GNU > General Public Licence, version 2 or later Thank you very much. For info: This is for the patch in

backporting translations

Richard, this might be interesting to you: After my latest fixes for mergepo.py in 2.3-staging it is quite easy to transfer translations between different branches. Assuming that you have two different branches, and in both branches no strings have been changed after the latest remerge, you

Re: [patch] Re: Double hyphens/en dashes in LyX-Code

Scott Kostyshak wrote: > Please commit. Done at dc38ae873a8b. Georg

Re: po files

Kornel Benko wrote: > > I was not accusing anyone. No problem. I interpreted the exclamation mark like it was not clear why the commit wnet to master. Georg

Re: po files

Kornel Benko wrote: > No, I compared with the file in repository. > Why do we have POTFILES.in in repo? It should not be there, and I can't see it in the repo. > Thanks, that explains it. I was misled by your last commit to (master!) > fr.gmo. Scott said in this thread that he was fine with

Re: po files

Kornel Benko wrote: > Am Sonntag, 24. April 2016 um 11:20:16, schrieb Georg Baum > <georg.b...@post.rwth-aachen.de> >> Kornel Benko wrote: >> >> > Am Samstag, 23. April 2016 um 12:01:32, schrieb Kornel Benko >> >> Hm, there are more d

[patch] Re: Double hyphens/en dashes in LyX-Code

Andrew Parsloe wrote: > http://www.lyx.org/trac/ticket/10074. This is a regression since they > display correctly as two hyphens in 2.1.4 in all cases (default, > emphasis, bolding, colour). Thank you very much for reporting this. I did indeed make a mistake when I removed the special meaning

Re: po files

Kornel Benko wrote: > Am Samstag, 23. April 2016 um 12:01:32, schrieb Kornel Benko >> Hm, there are more differences. In cmake we add also header files to the >> list. But I wonder, why unix command 'sort' is not working the same as >> cmake internal sort. > > OK, setting env LC_ALL=C, sort

Re: po files

Scott Kostyshak wrote: > On Thu, Apr 21, 2016 at 10:20:53PM +0200, Georg Baum wrote: > >> Unless somebody has an idea how to quickly work around the line ending >> bug my guess would be that the best option would be that Uwe does the >> remerge, then sends the resulti

Re: po files

Jean-Marc Lasgouttes wrote: > Le 22/04/2016 07:14, Georg Baum a écrit : >> After the remerge with cmake, I get >> this in the diff of de.po (the last remerge of it was on windows): >> >> -#: src/frontends/qt4/ui/BibitemUi.ui:54 >> src/frontends/qt4/ui/RefUi.u

Re: po files

Kornel Benko wrote: > Am Donnerstag, 21. April 2016 um 22:20:53, schrieb Georg Baum > <georg.b...@post.rwth-aachen.de> >> This is unfortunately difficult: >> >> - If Uwe does a remerge we will get the broken line endings again. >> - If Jean-Pierre or I do a

Re: po files

Scott Kostyshak wrote: > On Thu, Apr 21, 2016 at 08:13:18AM +0100, Jean-Pierre Chrétien wrote: >> Le 20/04/2016 18:19, Scott Kostyshak a écrit : >> > On Wed, Apr 20, 2016 at 02:19:50PM +0100, Jean-Pierre Chrétien wrote: >> >> > > There has been a remerge since my last update, without new >> > >

Re: Staging Branches [REVISED]

Richard Heck wrote: > The other two 2.2.x-staging branches are entirely for book-keeping > purposes. It is just easier for me to have the various fixes that are > intended for 2.2.1 and 2.2.2 in git branches rather than to try to keep > track of them via milestones or keywords or whatever in

Re: master is locked for 2.2.0rc1 preparation

Scott Kostyshak wrote: > On Thu, Apr 14, 2016 at 09:08:50PM +0200, Georg Baum wrote: > >> PS: Since RC is "Release candidate" we should IMHO only allow really >> critical bug fixes between RC1 and 2.2.0 final. In particular I think we >> should not do a RC2. >

Re: Staging Branches [REVISED]

Richard Heck wrote: > We now have three staging branches. These are: > > 2.3-staging > 2.2.1-staging > 2.2.2-staging That makes 5 active branches in total (please correct me if I misunderstood something): 2.1.x => will become 2.1.5 master => will become 2.2.0

Re: 2.2.0rc1 update

Uwe Stöhr wrote: > Not from my side. I would only like that the po-files are remerged so > that our translators can do their work after RC1 is released. Does that mean we had string changes again? I thougt that the strings in .po files were up to date after your last remerge. Georg

Re: po-files with trailing

Kornel Benko wrote: > Am Donnerstag, 7. April 2016 um 17:02:42, schrieb Richard Heck > >> >> Maybe a simple solution would be to add something into CMakeLists.txt >> that would strip all the "\r" before sending the files through gettext. > > Maybe, see my other mail. But I

Re: [PATCH] Re: po-files with trailing

Richard Heck wrote: > On 04/09/2016 11:36 AM, Uwe Stöhr wrote: >> Am 07.04.2016 um 23:37 schrieb Richard Heck: >> >>> Then maybe the solution is to disable the writing of native line >>> endings. Apparently, we can do this by opening the output files in >>> binary mode. The attached patch does

Re: [LyX/master] New layout for aastex6.cls. Fixes #10027.

Scott Kostyshak wrote: > On Sat, Apr 09, 2016 at 10:00:24AM +, Guenter Milde wrote: > >> I'd like to see all Unicode characters allowed in LyX labels but agree >> that this is stuff for 2.3... Agreed to both. > Yes and just to add I tested that the unicode strings shows up fine in > LyX so

Re: Double hyphens/en dashes in LyX-Code

Andrew Parsloe wrote: > Double hyphens in LyX-Code are now not merged to an en dash in rc1, > either in LyX or the pdf. Good. But if the font is changed, they become > an en dash in the pdf -- even something as simple as emphasis or bolding > has this effect. Is this expected behaviour? (I was

Re: master is locked for 2.2.0rc1 preparation

Richard Heck wrote: > Then I propose to go ahead and create 2.3-staging and 2.2.1-staging now. > The former will be open for all commits, as if it were master, and will > eventually be merged to master; the latter will be treated as stable and > will be managed by me alongside 2.1.x. Why so many

Re: master is locked for 2.2.0rc1 preparation

Jean-Marc Lasgouttes wrote: > I would like also to see a strategy for 2.2.1. Do we reserve this > milestone for urgent fixes and keep 2.2.2 for more mundane backports? Or > do we treat it just like any other stable release. I would recommend to reserve it for urgent fixes. I have made very good

Re: possible tag and tar of 2.2.0rc1 on Tuesday

Scott Kostyshak wrote: > On Wed, Apr 06, 2016 at 10:19:51PM +0200, Georg Baum wrote: >> Scott Kostyshak wrote: >> >> > On Tue, Apr 05, 2016 at 08:40:39AM +0200, Georg Baum wrote: >> >> The current status is now (see the docs list for details): >>

<    1   2   3   4   5   6   7   8   9   10   >