Am Donnerstag, 21. Januar 2016 um 00:30:26, schrieb Uwe Stöhr
> Am 19.01.2016 um 23:31 schrieb Peter Kümmel:
>
> > setting LYX_BUILD could be done at any time.
> >
> > And each run ensures LYX_BUILD exists, then removed LYX_BUILD and then
> > creates it again:
> >
> > mkdir %LYX_BUILD%
> > rmdir
Am 19.01.2016 um 23:31 schrieb Peter Kümmel:
setting LYX_BUILD could be done at any time.
And each run ensures LYX_BUILD exists, then removed LYX_BUILD and then
creates it again:
mkdir %LYX_BUILD%
rmdir /s/q %LYX_BUILD%
mkdir %LYX_BUILD%
So LYX_BUILD is always empty at the beginning.
OK, t
Am 19.01.2016 um 22:36 schrieb Stephan Witt:
I wrote this once somewhere and that is why I set up my git folder this way.
I meant I read this somewhere.
Then I propose to make this location a parameter too. It really shouldn’t be
inside the git repository.
OK.
regards Uwe
Am 19.01.2016 um 22:09 schrieb Uwe Stöhr:
Am 19.01.2016 um 17:15 schrieb Peter Kümmel:
I'll move them again out of the source tree.
But then users might have a problem. For example my git older for master
is D:\LyXGit\Master. It is forbidden to create a new folder in
D:\LyXGit to assure tha
Am 19.01.2016 um 22:09 schrieb Uwe Stöhr :
>
> Am 19.01.2016 um 17:15 schrieb Peter Kümmel:
>
>> I'll move them again out of the source tree.
>
> But then users might have a problem. For example my git older for master is
> D:\LyXGit\Master. It is forbidden to create a new folder in
> D:\LyXGit
Am 19.01.2016 um 17:15 schrieb Peter Kümmel:
I'll move them again out of the source tree.
But then users might have a problem. For example my git older for master
is D:\LyXGit\Master. It is forbidden to create a new folder in
D:\LyXGit
to assure that no folders can be deleted there. (E.g. th
Am 19.01.2016 um 02:24 schrieb Uwe Stöhr:
Am 18.01.2016 um 10:18 schrieb Peter Kümmel:
Maybe there is still a Qt 4 qmake.exe in PATH.
No, the solution are path changes:
- Qt is installed here in
C:\Qt\Qt5-5-1-2010\5.5\msvc2010\bin
Ah, this explains all problems!
not in
C:\Qt\
Am 18.01.2016 um 10:18 schrieb Peter Kümmel:
Maybe there is still a Qt 4 qmake.exe in PATH.
No, the solution are path changes:
- Qt is installed here in
C:\Qt\Qt5-5-1-2010\5.5\msvc2010\bin
not in
C:\Qt\Qt5.5.1-2010\5.5\msvc2010\bin
(don't know why, I could change that if you prefer)
Am 18. Januar 2016 09:20:32 MEZ, schrieb "Uwe Stöhr" :
>
>
>From: Peter Kümmel
>
>Sent: Montag, 18. Januar 2016 03:26
>
>
>> Do you mean you have to specify the Qt pathes in the installer
>script?
>
>
>No, in CMake as I wrote. My Script works fine.
>
>
>Regards Uwe
Maybe there is still a Qt 4 qm
Am 18. Januar 2016 00:56:50 MEZ, schrieb "Uwe Stöhr" :
>Am 15.01.2016 um 22:33 schrieb Georg Baum:
>
>> 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
Am 18. Januar 2016 00:56:50 MEZ, schrieb "Uwe Stöhr" :
>Am 15.01.2016 um 22:33 schrieb Georg Baum:
>
>> 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
Am 15.01.2016 um 22:33 schrieb Georg Baum:
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 a
On Sat, Jan 16, 2016 at 12:02:52PM +0100, Peter Kümmel wrote:
> >Am 13.01.2016 um 00:21 schrieb Uwe Stöhr:
> >>CMake. As soon as I create a new folder and copy there code, I need to
> >>run CMake from scratch and specify about 40 paths (most of them to Qt).
> >>If I make a mistake there I get stran
On Sat, Jan 16, 2016 at 12:13:54PM +0100, Peter Kümmel wrote:
>
> Am 15.01.2016 um 22:33 schrieb Georg Baum:
> >
> >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/t
Am 15.01.2016 um 22:33 schrieb Georg Baum:
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.
Am 13.01.2016 um 00:21 schrieb Uwe Stöhr:
CMake. As soon as I create a new folder and copy there code, I need to
run CMake from scratch and specify about 40 paths (most of them to Qt).
If I make a mistake there I get strange builds.
Uwe, why do you waste you time with such a msvc2010 fiddling?
Am 15.01.2016 um 22:39 schrieb 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 reprod
Am 15.01.2016 um 16:19 schrieb 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
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
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,
> 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
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
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
fid
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
>>
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
On Thu, Jan 14, 2016 at 02:47:28AM +0100, Uwe Stöhr wrote:
> Am 03.01.2016 um 17:15 schrieb Scott Kostyshak:
>
> >I don't understand how installers work for 32-bit vs 64-bit. Normally
> >does our Windows installer contain both 32-bit and 64-bit binaries?
>
> It contains only a 32bit version. Only
Am Donnerstag, 14. Januar 2016 um 23:32:08, 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.
> >
>
Am 14.01.2016 um 18:03 schrieb Guenter Milde:
If Ignacio give his OK, then fine with me.
How do I find out?
Please send him an email (CCed him). He is currently translating the
docs and he uses Spanish LyX for daily work.
Not necessary but helpfull. It would make the documents more "robu
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 fr
Am 14.01.2016 um 02:22 schrieb Uwe Stöhr:
Am 13.01.2016 um 01:20 schrieb Peter Kümmel:
Plain building should work now. But i dont know what comes after that,
to get a real installer.
- Download the installer source file:
http://ftp.lyx.de/LyX%202.2.0-test/LyXPackageComplete220-test.zip.file
Am Donnerstag, 14. Januar 2016 um 21:22:43, schrieb Georg Baum
> Am 13.01.2016 um 00:21 schrieb Uwe Stöhr:
> > Am 12.01.2016 um 19:43 schrieb Georg Baum:
> >
> >> Sorry, I still do not understand. Which paths need to be setup? What
> >> takes
> >> long (a manual step or some program that runs)?
Am 13.01.2016 um 00:21 schrieb Uwe Stöhr:
Am 12.01.2016 um 19:43 schrieb Georg Baum:
Sorry, I still do not understand. Which paths need to be setup? What
takes
long (a manual step or some program that runs)?
CMake. As soon as I create a new folder and copy there code, I need to
run CMake fr
Dear Uwe,
On 2016-01-10, Uwe Stöhr wrote:
>> GM1: could we add a line
>> \@ifpackageloaded{fontspec}{\unaccentedoperators}{}
>> to the user-preamble of doc/es/UserGuide.lyx?
>> This would work around a bug in babel-spanish preventing
>> compilation with non-TeX fonts
Am 03.01.2016 um 17:15 schrieb Scott Kostyshak:
I don't understand how installers work for 32-bit vs 64-bit. Normally
does our Windows installer contain both 32-bit and 64-bit binaries?
It contains only a 32bit version. Only with MSVC 2013 or never it is
possible to compile LyX as 64bit appli
Am 13.01.2016 um 01:20 schrieb Peter Kümmel:
Plain building should work now. But i dont know what comes after that, to get a
real installer.
- Download the installer source file:
http://ftp.lyx.de/LyX%202.2.0-test/LyXPackageComplete220-test.zip.filepart
- unzip it and follow the instruction
Am 13. Januar 2016 00:21:52 MEZ, schrieb "Uwe Stöhr" :
>Am 12.01.2016 um 19:43 schrieb Georg Baum:
>
>>> For now I also need the info about Qt 5. What is the expected build
>>> target for beta1? My time is limited and I have to focus on one Qt
>>> version. I installed Qt 5.6 beta for mingw and ming
My time is limited and I have to focus onone Qt
>>> version. I installed Qt 5.6 beta for mingw and mingw itself. Is this
>the way I should go?
>>
>> Yes, that would be great!
>
>Hi Peter,
>
>OK, I will try this. Since I never used MinGW I expect some obstacles
>and will contact you. OK?
Sure! Pla
Am 12.01.2016 um 00:55 schrieb Kornel Benko:
* for hunspell_include_dir I get this path:
D:/LyXGit/Master/3rdparty/hunspell/1.3.3/src
* for iconv_include_dir I get this path:
D:/LyXGit/Master/compile-2010/libiconv/include
This seems wrong to me. I expect that in both cases the files from
D:/LyX
On Wed, Jan 13, 2016 at 12:21:52AM +0100, Uwe Stöhr wrote:
> For Qt 5.6 I will use MinGW and not MSVC. Since both are new programs to me
> I think it makes sense to release beta1 with 5.5 if possible if Scott
> agrees.
I do agree with 5.5.1. I just started a new thread for this:
https://www.mail-
Am 12.01.2016 um 19:43 schrieb Georg Baum:
For now I also need the info about Qt 5. What is the expected build
target for beta1? My time is limited and I have to focus on one Qt
version. I installed Qt 5.6 beta for mingw and mingw itself. Is this the
way I should go?
That depends whether you w
Am 12.01.2016 um 11:23 schrieb Peter Kümmel:
For now I also need the info about Qt 5. What is the expected build
target for beta1? My time is limited and I have to focus on one Qt
version. I installed Qt 5.6 beta for mingw and mingw itself. Is this the
way I should go?
Yes, that would be great
The cache needs to be deleted (as you discovered already).
I'll push a script which deletes the complete build dir, cleanest way.
For now I also need the info about Qt 5. What is the expected build
target for beta1? My time is limited and I have to focus on one Qt
version. I installed Qt 5.6
Uwe Stöhr wrote:
> Am 11.01.2016 um 21:22 schrieb Georg Baum:
>
>> I don't know whether he got them from you or directly from the original
>> download pages, but this does not matter. What matters is that you get a
>> consistent build and eliminate possible errors if you use these sources
>> (by
For now I also need the info about Qt 5. What is the expected build
target for beta1? My time is limited and I have to focus on one Qt
version. I installed Qt 5.6 beta for mingw and mingw itself. Is this the
way I should go?
Yes, that would be great!
It looks like the paths will also not change
On Mon, Jan 11, 2016 at 12:45:11AM +0100, Uwe Stöhr wrote:
> My question: what is the plan for LyX 2.2.0: Do we release with Qt 5.6 or
> not? Should I try out its beta version?
My opinion is that we should only use Qt 5.6 for the final LyX 2.1
release if we use Qt 5.6beta for LyX 2.1beta1. From w
Am 12.01.2016 um 00:25 schrieb Uwe Stöhr:
GuiBibtex.cpp
..\..\..\..\src\frontends\qt4\GuiApplication.cpp(134): fatal error
C1083: Datei (Include) kann nicht geöffnet werden: "QWinMime": No such
file or directory
[D:\LyXGit\Master\compile-2010\src\frontends\qt4\frontend_qt.vcxproj]
This is an
Am Dienstag, 12. Januar 2016 um 00:25:37, schrieb Uwe Stöhr
> Am 11.01.2016 um 23:50 schrieb Kornel Benko:
>
> > it is -DLYX_3RDPARTY_BUILD=ON added to the call to cmake.
>
> I tried this but it won't work.
>
> What I did now is:
> - delete everything from CMake (cache)
> - run Cmake from scratch
Am 11.01.2016 um 23:50 schrieb Kornel Benko:
it is -DLYX_3RDPARTY_BUILD=ON added to the call to cmake.
I tried this but it won't work.
What I did now is:
- delete everything from CMake (cache)
- run Cmake from scratch
This way found bugs:
* for hunspell_include_dir I get this path:
D:/LyXGi
Am Montag, 11. Januar 2016 um 23:37:12, schrieb Uwe Stöhr
> Am 11.01.2016 um 21:22 schrieb Georg Baum:
>
> > I don't know whether he got them from you or directly from the original
> > download pages, but this does not matter. What matters is that you get a
> > consistent build and eliminate poss
Am 11.01.2016 um 21:22 schrieb Georg Baum:
I don't know whether he got them from you or directly from the original
download pages, but this does not matter. What matters is that you get a
consistent build and eliminate possible errors if you use these sources (by
enabling the 3RDPARTY_BUILD swit
Uwe Stöhr wrote:
> Am 10.01.2016 um 22:21 schrieb Scott Kostyshak:
>
>> G1. Not a question but a prerequisite IMHO: The 2.2.0 release should also
>> build the prerequisite from the sources Peter added, using exactly the
>> same compiler as is used to build LyX.
>
> It seems the sources Peter add
Am 10.01.2016 um 22:21 schrieb Scott Kostyshak:
I hope your trip went OK.
Hi all,
a happy new year. I am just back so don't expect too much - I have also
a real life.
Do you have an idea of when you will be able to get
back to LyX development?
Tomorrow.
It would be nice to know so we
On Sat, Jan 09, 2016 at 06:03:07PM -0500, Scott Kostyshak wrote:
> On Sat, Jan 09, 2016 at 11:58:16AM +0100, Peter Kümmel wrote:
> >
> >
> > Am 09.01.2016 um 01:32 schrieb Scott Kostyshak:
>
> > >S1. Would it be reasonable to build beta1 installers with both Qt 5.5.1
> > >and 5.6.0beta1?
> >
>
Hi Uwe,
I hope your trip went OK. Do you have an idea of when you will be able to get
back to LyX development? It would be nice to know so we can get an idea of when
to release beta1. Since we know you are busy, we have aggregated most of our
questions for you into one email.
The following letter
On Sat, Jan 09, 2016 at 11:58:16AM +0100, Peter Kümmel wrote:
>
>
> Am 09.01.2016 um 01:32 schrieb Scott Kostyshak:
> >S1. Would it be reasonable to build beta1 installers with both Qt 5.5.1
> >and 5.6.0beta1?
>
> There will be no downloadable msvc2010 builds for 5.6. ATM only 5.5.1:
>
> http:
On 2016-01-09, Scott Kostyshak wrote:
> I have gone through this thread and tried to make a summary of the questions
> and discussion for Uwe. Please add more questions if you have any or edit my
> misinterpretation of the question/comment.
> The following letters refer to the person that asked t
Am 09.01.2016 um 01:32 schrieb Scott Kostyshak:
On Mon, Jan 04, 2016 at 10:58:13AM -0500, Scott Kostyshak wrote:
On Mon, Jan 04, 2016 at 08:56:38AM -0500, Scott Kostyshak wrote:
On Sun, Jan 03, 2016 at 08:05:17PM +0100, Georg Baum wrote:
Scott Kostyshak wrote:
I don't understand how instal
On Mon, Jan 04, 2016 at 10:58:13AM -0500, Scott Kostyshak wrote:
> On Mon, Jan 04, 2016 at 08:56:38AM -0500, Scott Kostyshak wrote:
> > On Sun, Jan 03, 2016 at 08:05:17PM +0100, Georg Baum wrote:
> > > Scott Kostyshak wrote:
> > >
> > > > I don't understand how installers work for 32-bit vs 64-bit
Am 06.01.2016 um 13:32 schrieb Peter Kümmel:
4. Do we also want to try releasing an installer built
with mingw?
(Does that build an installer? or just LyX?)
It builds just LyX. Building an installer needs a built
LyX, it should not
matter whether it was built by MSVC or mingw (except for
the
Am 06.01.2016 um 14:35 schrieb Kornel Benko:
Am Mittwoch, 6. Januar 2016 um 14:27:24, schrieb Peter Kümmel
Am 03.01.2016 um 17:09 schrieb Kornel Benko:
It creates LyX22-2.2.0-win32.zip.
Probably not an installer like used in windows.
Yes, only the files generated my "make install".
I ad
Le 06/01/2016 14:23, Kornel Benko a écrit :
Is there a reason why we cannot use int64_t instead of long long?
Or maybe just use size_t and ptrdiff_t? I suspect these are the ones we
really need.
JMarc
Am 06.01.2016 um 14:23 schrieb Kornel Benko:
Am Mittwoch, 6. Januar 2016 um 14:15:22, schrieb Stephan Witt
Am 06.01.2016 um 13:35 schrieb Peter Kümmel :
Am 03.01.2016 um 20:05 schrieb Georg Baum:
So far we have never released any 64bit windows binary. This is fine, since
64bit windows c
Am Mittwoch, 6. Januar 2016 um 14:27:24, schrieb Peter Kümmel
> Am 03.01.2016 um 17:09 schrieb Kornel Benko:
> >
> > It creates LyX22-2.2.0-win32.zip.
> > Probably not an installer like used in windows.
>
> Yes, only the files generated my "make install".
>
> I added "make install" to the scrip
Am 06.01.2016 um 14:15 schrieb Stephan Witt:
Am 06.01.2016 um 13:35 schrieb Peter Kümmel :
Am 03.01.2016 um 20:05 schrieb Georg Baum:
So far we have never released any 64bit windows binary. This is fine, since
64bit windows can execute 32bit binaries, and nobody complained yet about
LyX h
Am 03.01.2016 um 17:09 schrieb Kornel Benko:
It creates LyX22-2.2.0-win32.zip.
Probably not an installer like used in windows.
Yes, only the files generated my "make install".
I added "make install" to the script, and the NSIS
installer should use the files in LYX_INSTALLED/
Kornel
Am Mittwoch, 6. Januar 2016 um 14:15:22, schrieb Stephan Witt
> Am 06.01.2016 um 13:35 schrieb Peter Kümmel :
> >
> >
> >
> > Am 03.01.2016 um 20:05 schrieb Georg Baum:
> >>
> >> So far we have never released any 64bit windows binary. This is fine, since
> >> 64bit windows can execute 32bit bi
Am 06.01.2016 um 13:35 schrieb Peter Kümmel :
>
>
>
> Am 03.01.2016 um 20:05 schrieb Georg Baum:
>>
>> So far we have never released any 64bit windows binary. This is fine, since
>> 64bit windows can execute 32bit binaries, and nobody complained yet about
>> LyX hitting the 32bit memory limit (
Am 03.01.2016 um 20:05 schrieb Georg Baum:
So far we have never released any 64bit windows binary. This is fine, since
64bit windows can execute 32bit binaries, and nobody complained yet about
LyX hitting the 32bit memory limit (around 3.5 GB on windows). I would not
switch to 64bit at this ti
4. Do we also want to try releasing an installer built with mingw?
(Does that build an installer? or just LyX?)
It builds just LyX. Building an installer needs a built LyX, it should not
matter whether it was built by MSVC or mingw (except for the MSVC
prerequisites, these are not needed to be i
On Mon, Jan 04, 2016 at 08:56:38AM -0500, Scott Kostyshak wrote:
> On Sun, Jan 03, 2016 at 08:05:17PM +0100, Georg Baum wrote:
> > Scott Kostyshak wrote:
> >
> > > I don't understand how installers work for 32-bit vs 64-bit. Normally
> > > does our Windows installer contain both 32-bit and 64-bit
On Sun, Jan 03, 2016 at 08:05:17PM +0100, Georg Baum wrote:
> Scott Kostyshak wrote:
>
> > I don't understand how installers work for 32-bit vs 64-bit. Normally
> > does our Windows installer contain both 32-bit and 64-bit binaries? Or
> > we just release 32-bit and 64-bit systems are fine with it
e to release beta1
>> > > soon after he is back so it would be nice to consolidate some
>> > > questions we might have for him so he has just one email that he
>> > > needs to look at. Do you have any questions for him regarding matters
>> > > tha
il that he needs to look at. Do
> >>>> you have any questions for him regarding matters that should be
> >>>> addressed for beta1?
> >>>>
> >>>> My questions for Uwe:
> >>>>
> >>>> 1. Would it be reasonable
s. It would be nice to release beta1 soon
>>>> after he is back so it would be nice to consolidate some questions we
>>>> might have for him so he has just one email that he needs to look at. Do
>>>> you have any questions for him regarding matters that s
is back so it would be nice to consolidate some questions we
> > > might have for him so he has just one email that he needs to look at. Do
> > > you have any questions for him regarding matters that should be
> > > addressed for beta1?
> > >
> > > My
or him so he has just one email that he needs to look at. Do
> > you have any questions for him regarding matters that should be
> > addressed for beta1?
> >
> > My questions for Uwe:
> >
> > 1. Would it be reasonable to build beta1 installers with both Qt 5.5.1
&
uestions for him regarding matters that should be
> addressed for beta1?
>
> My questions for Uwe:
>
> 1. Would it be reasonable to build beta1 installers with both Qt 5.5.1
> and 5.6.0beta1?
>
> 2. Can you make the installers from *only* the tar ball (and not use the
>
?
My questions for Uwe:
1. Would it be reasonable to build beta1 installers with both Qt 5.5.1
and 5.6.0beta1?
2. Can you make the installers from *only* the tar ball (and not use the
git directory at all)?
3. Can you confirm that all translation updates we have received have
been merged?
Scott
79 matches
Mail list logo
