Re: Beta 1
On Monday, May 24, 2021 8:18:31 PM WEST Richard Kimberly Heck wrote: > Hi, all, > > I have put tarballs for beta 1 here: > > https://drive.google.com/drive/folders/1Zl_20mzi9ndDDQdzeFyvR07O4lLDtcW3?usp > =sharing > > I need to get my IP updated with our FTP people before I can upload > again to ftp.lyx.org. Usually that does not take too long. In any event, > please prepare binaries, and I'll release later this week. > > Riki I have built for Centos-7 and 8 and for Fedora 32-35 (35 being the development version). All the builds succeeded and are available at the usual place: https://copr.fedorainfracloud.org/coprs/jamatos/lyx-devel/ Best regards, -- José Abílio-- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Beta 1
Am Do., 27. Mai 2021 um 22:49 Uhr schrieb Yu Jin : > Am Do., 27. Mai 2021 um 20:17 Uhr schrieb Yu Jin : > >> Am Mo., 24. Mai 2021 um 21:18 Uhr schrieb Richard Kimberly Heck < >> rikih...@lyx.org>: >> >>> Hi, all, >>> >>> I have put tarballs for beta 1 here: >>> >>> >>> https://drive.google.com/drive/folders/1Zl_20mzi9ndDDQdzeFyvR07O4lLDtcW3?usp=sharing >>> >>> I need to get my IP updated with our FTP people before I can upload >>> again to ftp.lyx.org. Usually that does not take too long. In any >>> event, >>> please prepare binaries, and I'll release later this week. >>> >> >> Unfortunately these don't compile for me, I get these errors: >> >> Severity Code Description Project File Line Suppression State >> Error C2664 'BOOL WaitNamedPipeW(LPCWSTR,DWORD)': cannot convert argument >> 1 from 'const _Elem *' to 'LPCWSTR' LyX (applications\LyX\LyX) >> C:\lyx\lyx-2.4.0-beta1\src\Server.cpp 530 >> Error C2664 'HANDLE >> CreateNamedPipeW(LPCWSTR,DWORD,DWORD,DWORD,DWORD,DWORD,DWORD,LPSECURITY_ATTRIBUTES)': >> cannot convert argument 1 from 'const _Elem *' to 'LPCWSTR' LyX >> (applications\LyX\LyX) C:\lyx\lyx-2.4.0-beta1\src\Server.cpp 178 >> Error C2664 'HANDLE >> CreateNamedPipeW(LPCWSTR,DWORD,DWORD,DWORD,DWORD,DWORD,DWORD,LPSECURITY_ATTRIBUTES)': >> cannot convert argument 1 from 'const _Elem *' to 'LPCWSTR' LyX >> (applications\LyX\LyX) C:\lyx\lyx-2.4.0-beta1\src\Server.cpp 492 >> >> Only occurs when LYX_CONSOLE is disabled though, which is what we want >> for the beta release. >> > Ah, I see, it's because of the > > UNICODE > _UNICODE > > preprocessor definitions What to do about that then? > I removed those for these tarballs (see also the other thread which I just started) and successfully built LyX, so Uploaded the installer as usual (only 64 bit, as mentioned earlier). I guess this is a good time to see how Qt6 goes, since it is a beta. If people ask for 32 bit, I can still build it later. Hopefully the UNICODE thing gets resolved until the next release/beta. -- Eugene -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Beta 1
Am Do., 27. Mai 2021 um 20:17 Uhr schrieb Yu Jin : > Am Mo., 24. Mai 2021 um 21:18 Uhr schrieb Richard Kimberly Heck < > rikih...@lyx.org>: > >> Hi, all, >> >> I have put tarballs for beta 1 here: >> >> >> https://drive.google.com/drive/folders/1Zl_20mzi9ndDDQdzeFyvR07O4lLDtcW3?usp=sharing >> >> I need to get my IP updated with our FTP people before I can upload >> again to ftp.lyx.org. Usually that does not take too long. In any event, >> please prepare binaries, and I'll release later this week. >> > > Unfortunately these don't compile for me, I get these errors: > > Severity Code Description Project File Line Suppression State > Error C2664 'BOOL WaitNamedPipeW(LPCWSTR,DWORD)': cannot convert argument > 1 from 'const _Elem *' to 'LPCWSTR' LyX (applications\LyX\LyX) > C:\lyx\lyx-2.4.0-beta1\src\Server.cpp 530 > Error C2664 'HANDLE > CreateNamedPipeW(LPCWSTR,DWORD,DWORD,DWORD,DWORD,DWORD,DWORD,LPSECURITY_ATTRIBUTES)': > cannot convert argument 1 from 'const _Elem *' to 'LPCWSTR' LyX > (applications\LyX\LyX) C:\lyx\lyx-2.4.0-beta1\src\Server.cpp 178 > Error C2664 'HANDLE > CreateNamedPipeW(LPCWSTR,DWORD,DWORD,DWORD,DWORD,DWORD,DWORD,LPSECURITY_ATTRIBUTES)': > cannot convert argument 1 from 'const _Elem *' to 'LPCWSTR' LyX > (applications\LyX\LyX) C:\lyx\lyx-2.4.0-beta1\src\Server.cpp 492 > > Only occurs when LYX_CONSOLE is disabled though, which is what we want for > the beta release. > Ah, I see, it's because of the UNICODE _UNICODE preprocessor definitions What to do about that then? -- Eugene -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Beta 1
Am Mo., 24. Mai 2021 um 21:18 Uhr schrieb Richard Kimberly Heck < rikih...@lyx.org>: > Hi, all, > > I have put tarballs for beta 1 here: > > > https://drive.google.com/drive/folders/1Zl_20mzi9ndDDQdzeFyvR07O4lLDtcW3?usp=sharing > > I need to get my IP updated with our FTP people before I can upload > again to ftp.lyx.org. Usually that does not take too long. In any event, > please prepare binaries, and I'll release later this week. > Unfortunately these don't compile for me, I get these errors: Severity Code Description Project File Line Suppression State Error C2664 'BOOL WaitNamedPipeW(LPCWSTR,DWORD)': cannot convert argument 1 from 'const _Elem *' to 'LPCWSTR' LyX (applications\LyX\LyX) C:\lyx\lyx-2.4.0-beta1\src\Server.cpp 530 Error C2664 'HANDLE CreateNamedPipeW(LPCWSTR,DWORD,DWORD,DWORD,DWORD,DWORD,DWORD,LPSECURITY_ATTRIBUTES)': cannot convert argument 1 from 'const _Elem *' to 'LPCWSTR' LyX (applications\LyX\LyX) C:\lyx\lyx-2.4.0-beta1\src\Server.cpp 178 Error C2664 'HANDLE CreateNamedPipeW(LPCWSTR,DWORD,DWORD,DWORD,DWORD,DWORD,DWORD,LPSECURITY_ATTRIBUTES)': cannot convert argument 1 from 'const _Elem *' to 'LPCWSTR' LyX (applications\LyX\LyX) C:\lyx\lyx-2.4.0-beta1\src\Server.cpp 492 Only occurs when LYX_CONSOLE is disabled though, which is what we want for the beta release. -- Eugene -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Beta 1
On Mon, May 24, 2021 at 03:18:31PM -0400, Richard Kimberly Heck wrote: > Hi, all, > > I have put tarballs for beta 1 here: > > https://drive.google.com/drive/folders/1Zl_20mzi9ndDDQdzeFyvR07O4lLDtcW3?usp=sharing Seems to work on several different debian versions. ANNOUNCE file still contains alpha1 description and I think we should be upfront with epub support in the announce to possibly get some feedback. Pavel -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Beta 1
Am Mo., 24. Mai 2021 um 21:18 Uhr schrieb Richard Kimberly Heck < rikih...@lyx.org>: > Hi, all, > > I have put tarballs for beta 1 here: > > > https://drive.google.com/drive/folders/1Zl_20mzi9ndDDQdzeFyvR07O4lLDtcW3?usp=sharing > > I need to get my IP updated with our FTP people before I can upload > again to ftp.lyx.org. Usually that does not take too long. In any event, > please prepare binaries, and I'll release later this week. > Hi Riki, what do you think? Should I build the Windows installer with Qt 6.1? Qt 6 upwards only delivers precompiled 64 bit binaries, I'm not sure what I would do about that. The options would be to continue building with Qt 5, build 64 bit LyX with Qt 6 and 32 bit with Qt 5 (don't really want to build Qt 6 32 bit myself) or only build 64 bit LyX. That said I can't really imagine people still using 32 bit windows, so I would prefer the last option. -- Eugene -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Beta 1
Hi, all, I have put tarballs for beta 1 here: https://drive.google.com/drive/folders/1Zl_20mzi9ndDDQdzeFyvR07O4lLDtcW3?usp=sharing I need to get my IP updated with our FTP people before I can upload again to ftp.lyx.org. Usually that does not take too long. In any event, please prepare binaries, and I'll release later this week. Riki -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Beta 1
On Sun, Apr 11, 2021 at 02:25:11AM -0400, Richard Kimberly Heck wrote: > So how about a Beta 1 soon? Great idea, we should announce epub export available to get some testing. > I guess that means total feature freeze and only serious bug fixes in master. Feature freeze definitely, I would still allow format and string changes if it's parts of normal bugs targetted to 2.4. Maybe reseting 2.4 milestones in abandoned bugs would give clear picture what to expect :) > Do we start translations then? with the understanding that such string > changes henceforth should be essential only? I wouldn't do string freeze right now, but announce it's coming and translators can feel safe to start working, because additional changes will be small. Pavel -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Beta 1
Le 11/04/2021 à 08:25, Richard Kimberly Heck a écrit : Got kind of busy last month, but that has left some time for testing, and we seem not to have gotten too many reports of regressions. So how about a Beta 1 soon? I guess that means total feature freeze and only serious bug fixes in master. Do we start translations then? with the understanding that such string changes henceforth should be essential only? There is this inherotFont business that I neglected at the time because I did not realize that the interactions with display can be annoying. I would like to see if some things can be tweaked before we release a new file format that freezes some things. I have one bug that I'm very worried about. It seems to happen as follows. I have a master with a child (even just one). I am editing the child. I then compile the master (master-buffer-update, or whatever it is). If I try to edit the child while the compilation is under way, I get errors. Often this is "No aux file found". Then it is "Undefined citations". But it is especially noticeable if there is a macro defined in the master that is needed in the child. Then I get: Undefined command. This does not look good indeed. JMarc -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Beta 1
Got kind of busy last month, but that has left some time for testing, and we seem not to have gotten too many reports of regressions. So how about a Beta 1 soon? I guess that means total feature freeze and only serious bug fixes in master. Do we start translations then? with the understanding that such string changes henceforth should be essential only? I have one bug that I'm very worried about. It seems to happen as follows. I have a master with a child (even just one). I am editing the child. I then compile the master (master-buffer-update, or whatever it is). If I try to edit the child while the compilation is under way, I get errors. Often this is "No aux file found". Then it is "Undefined citations". But it is especially noticeable if there is a macro defined in the master that is needed in the child. Then I get: Undefined command. I have not had time to debug this, and I am not sure I can reproduce it reliably. But it happens on multiple machines. It feels as if something is resetting the parent for the child or else deleting the compiled files for the master when I try to edit the child. Riki -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Alpha 2? Beta 1?
Am Dienstag, dem 26.01.2021 um 10:32 +0200 schrieb Dr Eberhard Lisse: > to be honest ePub support is a killer feature (even for non- > publishing users like me) and hence I'd really would like to see it > making it into 2.4. With this argumentation a release can be delayed ad infinitum. Having written that, we have a release manager (Riki), and this is his call, not mine. Jürgen signature.asc Description: This is a digitally signed message part -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Alpha 2? Beta 1?
Jürgen, to be honest ePub support is a killer feature (even for non-publishing users like me) and hence I'd really would like to see it making it into 2.4. Alpha/Beta doesn't matter to me as I can't make the switch (new file structure?) until it is production ready (or 2.3.7 (?) can read 2.4 files), due to the nature of my day job. Both my desktops (office/home) and both laptops (office/home) sync with each other at least daily. greetings, el On 26/01/2021 09:51, Jürgen Spitzmüller wrote: [...] > Me, too. I would add that we shouldn't wait too long for new features. > So if the ePub support is not there within a to-be-specified time, > postpone it to a later release. > > OTOH I think a second alpha is fair if it is done soon. > > For beta, I would suggest to freeze features. > > Jürgen [...] -- To email me replace 'nospam' with 'el' -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Alpha 2? Beta 1?
On Monday, January 25, 2021 6:59:02 PM WET Thibaut Cuvelier wrote: > I would really like to ship an ePub export in 2.4, building upon the DocBook > export. I think I could work on that this week. In the interest of the discussion what needs to be done here? That is how do you intend to implement this export? -- José Abílio-- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Alpha 2? Beta 1?
Am Montag, dem 25.01.2021 um 19:52 + schrieb José Abílio Matos: > On Monday, January 25, 2021 7:26:34 PM WET Pavel Sanda wrote: > > But I don't think it matters much in the end, > > Pavel > > I agree with Pavel here. :-) Me, too. I would add that we shouldn't wait too long for new features. So if the ePub support is not there within a to-be-specified time, postpone it to a later release. OTOH I think a second alpha is fair if it is done soon. For beta, I would suggest to freeze features. Jürgen > > -- > José Abílio signature.asc Description: This is a digitally signed message part -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Alpha 2? Beta 1?
On Monday, January 25, 2021 7:26:34 PM WET Pavel Sanda wrote: > But I don't think it matters much in the end, > Pavel I agree with Pavel here. :-) -- José Abílio-- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Alpha 2? Beta 1?
On Mon, Jan 25, 2021 at 07:59:02PM +0100, Thibaut Cuvelier wrote: > > A couple fairly significant regressions have now been fixed in Alpha 1, > > so it looks like time to do another release. The default would be to go > > with Alpha 2. But, besides some missing layout files (my fault) and a > > problem opening files, we have not had any serious bug reports from > > Alpha 1 (that aren't already in 2.3.x). Should we think about a beta > > release? To be honest, I don't know myself what people think the > > difference is between the two, so I'd welcome suggestions. > > > > I would really like to ship an ePub export in 2.4, building upon the > DocBook export. I think I could work on that this week. This would be great. > For alpha vs. beta, I often see that alpha is near-release, but not yet > feature-frozen, while the developers would like feedback on the current > state of the software; beta is feature-frozen, with only bug fixes included > in one release to the other (RC meaning that only critical bug fixes are > being fixed). Per our own definitions alpha means only *few* new features are expected to happen for 2.4, beta means only *small* changes intended for 2.4. If you wait for ePub to finish then I think it's time for beta, if you want to push release now, then I'd still go with alpha. But I don't think it matters much in the end, Pavel -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Alpha 2? Beta 1?
On Mon, 25 Jan 2021 at 19:31, Richard Kimberly Heck wrote: > Hi, all, > > A couple fairly significant regressions have now been fixed in Alpha 1, > so it looks like time to do another release. The default would be to go > with Alpha 2. But, besides some missing layout files (my fault) and a > problem opening files, we have not had any serious bug reports from > Alpha 1 (that aren't already in 2.3.x). Should we think about a beta > release? To be honest, I don't know myself what people think the > difference is between the two, so I'd welcome suggestions. > I would really like to ship an ePub export in 2.4, building upon the DocBook export. I think I could work on that this week. For alpha vs. beta, I often see that alpha is near-release, but not yet feature-frozen, while the developers would like feedback on the current state of the software; beta is feature-frozen, with only bug fixes included in one release to the other (RC meaning that only critical bug fixes are being fixed). -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Alpha 2? Beta 1?
Hi, all, A couple fairly significant regressions have now been fixed in Alpha 1, so it looks like time to do another release. The default would be to go with Alpha 2. But, besides some missing layout files (my fault) and a problem opening files, we have not had any serious bug reports from Alpha 1 (that aren't already in 2.3.x). Should we think about a beta release? To be honest, I don't know myself what people think the difference is between the two, so I'd welcome suggestions. Riki -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: LyX version 2.3.0 (beta 1)
Kornel Benko wrote: > We may want to unify the output of msgmerge to possibly minimize the > differences in po-files. We tried and were not capable to unify it on Uwe's box, I am not going into the same debate again so it's completely your call. P
Re: LyX version 2.3.0 (beta 1)
Am Montag, 4. September 2017 um 02:28:33, schrieb Scott Kostyshak
> On Sun, Sep 03, 2017 at 11:11:55PM +0200, Kornel Benko wrote:
> > Am Donnerstag, 31. August 2017 um 13:07:46, schrieb Pavel Sanda
> >
> > > Scott Kostyshak wrote:
> > > > > I did not make any stats, cherrypicking single commit (likely close
> > > > > to worst-case) gives me uncompressed 45 megs in blobs:
> > > > > $ git diff-tree -r -c -M -C --no-commit-id cf5d9e1 |acut -f 4 | git
> > > > > cat-file --batch-check |acut -f 3|asum
> > > > > 45175575
> > > >
> > > > 45MB for all gmo commits ever? That does not seem bad at all to me. Good
> > > > to know.
> > >
> > > No, 45MB uncompressed per _single_ commit. P
> >
> > We may want to unify the output of msgmerge to possibly minimize the
> > differences in po-files.
> > For instance while remerging using '--width� --sort-output' may create the
> > same output on all platforms.
>
> I'm open to anything, but if there's something you want me specifically
> to do, please let me know the exact steps.
>
> Scott
Like the attached. (Not tested for automake)
The expected effect is big commit at next remerge (po-files only, no need to
remerge the gmo files too).
It should pay of on later remerges.
Korneldiff --git a/development/cmake/modules/FindLyXGettext.cmake b/development/cmake/modules/FindLyXGettext.cmake
index 8533cbf..3e8a9b0 100755
--- a/development/cmake/modules/FindLyXGettext.cmake
+++ b/development/cmake/modules/FindLyXGettext.cmake
@@ -51,7 +51,7 @@ MACRO(GETTEXT_CREATE_TRANSLATIONS _potFile _firstPoFile)
ADD_CUSTOM_COMMAND(
OUTPUT ${_gmoFile}
- COMMAND ${GETTEXT_MSGMERGE_EXECUTABLE} --quiet --update --backup=none ${_absFile} ${_absPotFile}
+ COMMAND ${GETTEXT_MSGMERGE_EXECUTABLE} --quiet --update --backup=none --width --sort-output ${_absFile} ${_absPotFile}
COMMAND ${GETTEXT_MSGFMT_EXECUTABLE} -c --statistics -o ${_gmoFile}.1 ${_absFile}
COMMAND ${CMAKE_COMMAND} -E rename ${_gmoFile}.1 ${_gmoFile}
DEPENDS ${_absPotFile} ${_absFile}
diff --git a/po/Makevars.template b/po/Makevars.template
index 0648ec7..c318c89 100644
--- a/po/Makevars.template
+++ b/po/Makevars.template
@@ -63,7 +63,7 @@ MSGMERGE_OPTIONS # If you want to disable line wrapping when writing PO files, add
# --no-wrap to MSGMERGE_OPTIONS, XGETTEXT_OPTIONS, and
# MSGINIT_OPTIONS.
-MSGINIT_OPTIONS +MSGINIT_OPTIONS = --width --sort-output
# This tells whether or not to regenerate a PO file when $(DOMAIN).pot
# has changed. Possible values are "yes" and "no". Set this to no if
signature.asc
Description: This is a digitally signed message part.
Re: LyX version 2.3.0 (beta 1)
On Sun, Sep 03, 2017 at 11:11:55PM +0200, Kornel Benko wrote: > Am Donnerstag, 31. August 2017 um 13:07:46, schrieb Pavel Sanda > > > Scott Kostyshak wrote: > > > > I did not make any stats, cherrypicking single commit (likely close to > > > > worst-case) gives me uncompressed 45 megs in blobs: > > > > $ git diff-tree -r -c -M -C --no-commit-id cf5d9e1 |acut -f 4 | git > > > > cat-file --batch-check |acut -f 3|asum > > > > 45175575 > > > > > > 45MB for all gmo commits ever? That does not seem bad at all to me. Good > > > to know. > > > > No, 45MB uncompressed per _single_ commit. P > > We may want to unify the output of msgmerge to possibly minimize the > differences in po-files. > For instance while remerging using '--width=80 --sort-output' may create the > same output on all platforms. I'm open to anything, but if there's something you want me specifically to do, please let me know the exact steps. Scott signature.asc Description: PGP signature
Re: LyX version 2.3.0 (beta 1)
Am Donnerstag, 31. August 2017 um 13:07:46, schrieb Pavel Sanda > Scott Kostyshak wrote: > > > I did not make any stats, cherrypicking single commit (likely close to > > > worst-case) gives me uncompressed 45 megs in blobs: > > > $ git diff-tree -r -c -M -C --no-commit-id cf5d9e1 |acut -f 4 | git > > > cat-file --batch-check |acut -f 3|asum > > > 45175575 > > > > 45MB for all gmo commits ever? That does not seem bad at all to me. Good > > to know. > > No, 45MB uncompressed per _single_ commit. P We may want to unify the output of msgmerge to possibly minimize the differences in po-files. For instance while remerging using '--width=80 --sort-output' may create the same output on all platforms. Kornel signature.asc Description: This is a digitally signed message part.
Re: LyX version 2.3.0 (beta 1)
On Thu, Aug 31, 2017 at 01:07:46PM +0200, Pavel Sanda wrote: > Scott Kostyshak wrote: > > > I did not make any stats, cherrypicking single commit (likely close to > > > worst-case) gives me uncompressed 45 megs in blobs: > > > $ git diff-tree -r -c -M -C --no-commit-id cf5d9e1 |acut -f 4 | git > > > cat-file --batch-check |acut -f 3|asum > > > 45175575 > > > > 45MB for all gmo commits ever? That does not seem bad at all to me. Good > > to know. > > No, 45MB uncompressed per _single_ commit. P Ah, thanks for the clarification. Scott signature.asc Description: PGP signature
Re: LyX version 2.3.0 (beta 1)
Scott Kostyshak wrote: > > I did not make any stats, cherrypicking single commit (likely close to > > worst-case) gives me uncompressed 45 megs in blobs: > > $ git diff-tree -r -c -M -C --no-commit-id cf5d9e1 |acut -f 4 | git > > cat-file --batch-check |acut -f 3|asum > > 45175575 > > 45MB for all gmo commits ever? That does not seem bad at all to me. Good > to know. No, 45MB uncompressed per _single_ commit. P
Re: LyX version 2.3.0 (beta 1)
On Wed, Aug 30, 2017 at 04:48:36PM +0200, Pavel Sanda wrote: > Scott Kostyshak wrote: > > > b) git archive become easily huge just because of such changes > > > > Do frequent commits of .gmo files significantly increase git archive? > > I did not make any stats, cherrypicking single commit (likely close to > worst-case) gives me uncompressed 45 megs in blobs: > $ git diff-tree -r -c -M -C --no-commit-id cf5d9e1 |acut -f 4 | git > cat-file --batch-check |acut -f 3|asum > 45175575 45MB for all gmo commits ever? That does not seem bad at all to me. Good to know. Scott signature.asc Description: PGP signature
Re: LyX version 2.3.0 (beta 1)
On 08/30/2017 04:32 AM, Scott Kostyshak wrote: > On Mon, Aug 28, 2017 at 11:08:52PM +0200, Pavel Sanda wrote: >> Scott Kostyshak wrote: >>> I think I have a fundamental misunderstanding. I thought that strings >>> were supposed to be remerged before asking translators for translations. >>> Then the translator returns the po file, and the po and the >>> corresponding gmo files are committed. What is the purpose of remerging >>> strings before a release? I was spoiled during 2.2.0 because I think >>> Georg and Uwe took care of all translation-related issues. That ended up >>> being a mistake because I realize that it is important for the release >>> manager to know all parts of the process, so I'm trying to learn. >> 1. Whenever new UI string is added or changed this change will propagate >> into .po files only via remerging strings. >> 2. Whenever new remerge is done *lot* of irrelevant stuff (i.e. source code >> lines for string) changes as well - resulting into huge diff. >>It gets even worse if different people do remerges because different >> archs produce slightly different formatting, resulting into even bigger >> patch (didn't check but we can easily talk megabytes per commit here). >> >> Point 1 implies it is good to remerge strings when you want translators >> working on up-to-date UI and if string change occurs (i.e. our minted flame). >> Point 2 implies you don't want to do it more often except when really >> neccessary because >> a) it creates hell when you do detailed seach through commit history via git >> log -p > Workaround (which does not negate your point of course since it is a > pain to remember): > > git log -p -- . ":(exclude)*.po" # git config alias.lognopo "log -p -- . ':(exclude)*.po'" # git lognopo Richard
Re: LyX version 2.3.0 (beta 1)
Scott Kostyshak wrote: > > b) git archive become easily huge just because of such changes > > Do frequent commits of .gmo files significantly increase git archive? I did not make any stats, cherrypicking single commit (likely close to worst-case) gives me uncompressed 45 megs in blobs: $ git diff-tree -r -c -M -C --no-commit-id cf5d9e1 |acut -f 4 | git cat-file --batch-check |acut -f 3|asum 45175575 You get similar size when looking at patch size: $ git show --binary cf5d9e1 > /tmp/patch $ ls -lh /tmp/patch -rw-r--r-- 1 xxx xxx 43M Aug 30 16:44 /tmp/patch $ tgz /tmp/patch #quick compress -rw-r--r-- 1 xxx xxx 11M Aug 30 16:46 patch.tgz Pavel
Re: LyX version 2.3.0 (beta 1)
On Mon, Aug 28, 2017 at 11:08:52PM +0200, Pavel Sanda wrote: > Scott Kostyshak wrote: > > I think I have a fundamental misunderstanding. I thought that strings > > were supposed to be remerged before asking translators for translations. > > Then the translator returns the po file, and the po and the > > corresponding gmo files are committed. What is the purpose of remerging > > strings before a release? I was spoiled during 2.2.0 because I think > > Georg and Uwe took care of all translation-related issues. That ended up > > being a mistake because I realize that it is important for the release > > manager to know all parts of the process, so I'm trying to learn. > > 1. Whenever new UI string is added or changed this change will propagate into > .po files only via remerging strings. > 2. Whenever new remerge is done *lot* of irrelevant stuff (i.e. source code > lines for string) changes as well - resulting into huge diff. >It gets even worse if different people do remerges because different archs > produce slightly different formatting, resulting into even bigger patch > (didn't check but we can easily talk megabytes per commit here). > > Point 1 implies it is good to remerge strings when you want translators > working on up-to-date UI and if string change occurs (i.e. our minted flame). > Point 2 implies you don't want to do it more often except when really > neccessary because > a) it creates hell when you do detailed seach through commit history via git > log -p Workaround (which does not negate your point of course since it is a pain to remember): git log -p -- . ":(exclude)*.po" > b) git archive become easily huge just because of such changes Do frequent commits of .gmo files significantly increase git archive? > So one has to find certain compromise between 1/2. I would say that when you > are close to release/string freeze then any string change is worth to remerge > & commit. > Also this time it's little easier because you already branched 2.3 so any > number of remerges won't spoil master history. > You can test necessity of remerge by checking stats in remerge (number of > translated/fuzzy/untranslated strings changes for some language which is not > under extreme care of maintainers who can do remerges of their language only > - typical case of de,sk,fr?,it?). > If you don't detect changes in stats, there is no need to remerge&commit for > realease just to update code lines, because remerge IIRC happens > automatically inside tarball creation machinery. > If you finally kick JMarc to give you svn access, regularly updated > translation status web page might be handy for you. > > Ask if you have any question, Thanks a lot for that detailed explanation. I will be more careful with this, and am now building up a better understanding. Scott signature.asc Description: PGP signature
Re: LyX version 2.3.0 (beta 1)
On Thu, Aug 17, 2017 at 8:25 PM, Scott Kostyshak wrote: > Public release of LyX version 2.3.0beta1 > > > Ubuntu 'lyx2.3pre' packages are now available on the Development PPA: https://launchpad.net/~lyx-devel/+archive/ubuntu/daily The packages install independently of your existing stable 2.2.x installation. Regards, Liviu > We are proud to announce the first public beta of the new LyX 2.3 series. > This pre-release is meant for testing and should not be used for serious > work. > For curious users who would like to test in order to help catch bugs before > the 2.3.0 release, please back up all of your documents and be prepared for > the worst to happen. Most users (who desire a stable LyX version) should > not > use this pre-release. > > The 2.3 series has a rich set of new features compared to the current > stable > series. An overview of the new features can be found here: > > http://wiki.lyx.org/LyX/NewInLyX23 > > You can download LyX 2.3.0beta1 from ftp://ftp.lyx.org/pub/lyx/devel/. > > We appreciate your help in testing this pre-release! > > The file lib/RELEASE-NOTES lists some known issues and problems compared > to the current stable releases (LyX 2.2.x). We strongly recommend that > packagers of LyX on various platforms and distributions read this file. > > As with any major release, this one comes with a lot of new features but > also some bugs. If you think you have found a bug in LyX 2.3.0beta1, either > email the LyX developers' mailing list (lyx-devel at lists.lyx.org), > or open a bug report at https://www.lyx.org/trac/wiki/BugTrackerHome. > Please specify if the behavior you are reporting is different from behavior > in a previous LyX version. > > If you have trouble using LyX or have a question, consult the > documentation that comes with LyX (under Help) and the LyX wiki, which you > will find at https://wiki.lyx.org/. You can also send email to the LyX > users' > list (lyx-users at lists.lyx.org). > > The LyX team. > https://www.lyx.org > >
Re: LyX version 2.3.0 (beta 1)
Scott Kostyshak wrote: > I think I have a fundamental misunderstanding. I thought that strings > were supposed to be remerged before asking translators for translations. > Then the translator returns the po file, and the po and the > corresponding gmo files are committed. What is the purpose of remerging > strings before a release? I was spoiled during 2.2.0 because I think > Georg and Uwe took care of all translation-related issues. That ended up > being a mistake because I realize that it is important for the release > manager to know all parts of the process, so I'm trying to learn. 1. Whenever new UI string is added or changed this change will propagate into .po files only via remerging strings. 2. Whenever new remerge is done *lot* of irrelevant stuff (i.e. source code lines for string) changes as well - resulting into huge diff. It gets even worse if different people do remerges because different archs produce slightly different formatting, resulting into even bigger patch (didn't check but we can easily talk megabytes per commit here). Point 1 implies it is good to remerge strings when you want translators working on up-to-date UI and if string change occurs (i.e. our minted flame). Point 2 implies you don't want to do it more often except when really neccessary because a) it creates hell when you do detailed seach through commit history via git log -p b) git archive become easily huge just because of such changes So one has to find certain compromise between 1/2. I would say that when you are close to release/string freeze then any string change is worth to remerge & commit. Also this time it's little easier because you already branched 2.3 so any number of remerges won't spoil master history. You can test necessity of remerge by checking stats in remerge (number of translated/fuzzy/untranslated strings changes for some language which is not under extreme care of maintainers who can do remerges of their language only - typical case of de,sk,fr?,it?). If you don't detect changes in stats, there is no need to remerge&commit for realease just to update code lines, because remerge IIRC happens automatically inside tarball creation machinery. If you finally kick JMarc to give you svn access, regularly updated translation status web page might be handy for you. Ask if you have any question, Pavel
Re: LyX version 2.3.0 (beta 1)
On 08/28/2017 01:09 AM, Scott Kostyshak wrote: > On Sun, Aug 27, 2017 at 03:23:42AM +0200, Pavel Sanda wrote: >> Scott Kostyshak wrote: >>> Public release of LyX version 2.3.0beta1 >> Scott, did you put on lyx wiki the release steps you are using when >> releasing tarballs? >> (If not, can you share it there?) > I just updated the wiki with the basic steps I am doing. I will try to > keep it updated as I make corrections (as it seems I should in the case > of merging strings). > > https://wiki.lyx.org/Devel/ReleaseProcedure#toc1 > > I hope to eventually organize all of my notes. I have some that are > organized as "only for alpha1", "only for beta1", etc., and other > informal things to check (e.g. for pre-releases use a different, > scarier, form of ANNOUNCE). > >> It seems strings were not properly remerged for beta. > I think I have a fundamental misunderstanding. I thought that strings > were supposed to be remerged before asking translators for translations. > Then the translator returns the po file, and the po and the > corresponding gmo files are committed. What is the purpose of remerging > strings before a release? I was spoiled during 2.2.0 because I think > Georg and Uwe took care of all translation-related issues. That ended up > being a mistake because I realize that it is important for the release > manager to know all parts of the process, so I'm trying to learn. I don't know the answer to this, but I do remerge strings before doing the mainteance releases, mostly because it said to do so on the wiki. (I've updated a lot of that myself now, so it's not as I found it.) Richard
Re: LyX version 2.3.0 (beta 1)
On Sun, Aug 27, 2017 at 03:23:42AM +0200, Pavel Sanda wrote: > Scott Kostyshak wrote: > > Public release of LyX version 2.3.0beta1 > > Scott, did you put on lyx wiki the release steps you are using when releasing > tarballs? > (If not, can you share it there?) I just updated the wiki with the basic steps I am doing. I will try to keep it updated as I make corrections (as it seems I should in the case of merging strings). https://wiki.lyx.org/Devel/ReleaseProcedure#toc1 I hope to eventually organize all of my notes. I have some that are organized as "only for alpha1", "only for beta1", etc., and other informal things to check (e.g. for pre-releases use a different, scarier, form of ANNOUNCE). > It seems strings were not properly remerged for beta. I think I have a fundamental misunderstanding. I thought that strings were supposed to be remerged before asking translators for translations. Then the translator returns the po file, and the po and the corresponding gmo files are committed. What is the purpose of remerging strings before a release? I was spoiled during 2.2.0 because I think Georg and Uwe took care of all translation-related issues. That ended up being a mistake because I realize that it is important for the release manager to know all parts of the process, so I'm trying to learn. Scott signature.asc Description: PGP signature
Re: LyX version 2.3.0 (beta 1)
Scott Kostyshak wrote: > Public release of LyX version 2.3.0beta1 Scott, did you put on lyx wiki the release steps you are using when releasing tarballs? (If not, can you share it there?) It seems strings were not properly remerged for beta. Pavel
Re: LyX version 2.3.0 (beta 1)
On Thu, Aug 24, 2017 at 09:41:44AM +0200, Enrico Forestieri wrote: > On Wed, Aug 23, 2017 at 09:38:04AM +0200, Enrico Forestieri wrote: > > Miscellaneous, I would say. > > I added it. Thanks, Scott signature.asc Description: PGP signature
Re: LyX version 2.3.0 (beta 1)
On Wed, Aug 23, 2017 at 09:38:04AM +0200, Enrico Forestieri wrote: > On Tue, Aug 22, 2017 at 10:33:51PM -0400, Scott Kostyshak wrote: > > On Fri, Aug 18, 2017 at 01:47:59AM -0400, Scott Kostyshak wrote: > > > On Thu, Aug 17, 2017 at 09:06:06PM +0200, Tommaso Cucinotta wrote: > > > > On 17/08/2017 20:25, Scott Kostyshak wrote: > > > > > An overview of the new features can be found here: > > > > > > > > > >http://wiki.lyx.org/LyX/NewInLyX23 > > > > > > > > AFAICR, the new shell-escape [+minted] support made it to the 2.3, but > > > > it's not mentioned (yet). > > > > > > Indeed, please feel free to put it. Or if you prefer that I do it that's > > > fine too. > > > > We do have the entry > > > > "Option to use the LaTeX package minted for the typesetting of code > > listings." > > > > We could add the shell-escape feature as a separate entry, but I'm not > > sure what we would put as the description. Something like the following? > > > > -shell-escape can now be enabled only for specific documents, rather > > than having to enable it globally in preferences. > > > > Which category should we put it? Miscellaneous or "Image formats and > > conversion"? > > Miscellaneous, I would say. I added it. -- Enrico
Re: LyX version 2.3.0 (beta 1)
On Tue, Aug 22, 2017 at 10:33:51PM -0400, Scott Kostyshak wrote: > On Fri, Aug 18, 2017 at 01:47:59AM -0400, Scott Kostyshak wrote: > > On Thu, Aug 17, 2017 at 09:06:06PM +0200, Tommaso Cucinotta wrote: > > > On 17/08/2017 20:25, Scott Kostyshak wrote: > > > > An overview of the new features can be found here: > > > > > > > >http://wiki.lyx.org/LyX/NewInLyX23 > > > > > > AFAICR, the new shell-escape [+minted] support made it to the 2.3, but > > > it's not mentioned (yet). > > > > Indeed, please feel free to put it. Or if you prefer that I do it that's > > fine too. > > We do have the entry > > "Option to use the LaTeX package minted for the typesetting of code > listings." > > We could add the shell-escape feature as a separate entry, but I'm not > sure what we would put as the description. Something like the following? > > -shell-escape can now be enabled only for specific documents, rather > than having to enable it globally in preferences. > > Which category should we put it? Miscellaneous or "Image formats and > conversion"? Miscellaneous, I would say. -- Enrico
Re: LyX version 2.3.0 (beta 1)
On Fri, Aug 18, 2017 at 01:47:59AM -0400, Scott Kostyshak wrote: > On Thu, Aug 17, 2017 at 09:06:06PM +0200, Tommaso Cucinotta wrote: > > On 17/08/2017 20:25, Scott Kostyshak wrote: > > > An overview of the new features can be found here: > > > > > >http://wiki.lyx.org/LyX/NewInLyX23 > > > > AFAICR, the new shell-escape [+minted] support made it to the 2.3, but it's > > not mentioned (yet). > > Indeed, please feel free to put it. Or if you prefer that I do it that's > fine too. We do have the entry "Option to use the LaTeX package minted for the typesetting of code listings." We could add the shell-escape feature as a separate entry, but I'm not sure what we would put as the description. Something like the following? -shell-escape can now be enabled only for specific documents, rather than having to enable it globally in preferences. Which category should we put it? Miscellaneous or "Image formats and conversion"? Scott signature.asc Description: PGP signature
Re: LyX version 2.3.0 (beta 1)
On Thu, Aug 17, 2017 at 09:06:06PM +0200, Tommaso Cucinotta wrote: > On 17/08/2017 20:25, Scott Kostyshak wrote: > > An overview of the new features can be found here: > > > >http://wiki.lyx.org/LyX/NewInLyX23 > > AFAICR, the new shell-escape [+minted] support made it to the 2.3, but it's > not mentioned (yet). Indeed, please feel free to put it. Or if you prefer that I do it that's fine too. Thanks for pointing it out, Scott signature.asc Description: PGP signature
Re: LyX version 2.3.0 (beta 1)
On 17/08/2017 20:25, Scott Kostyshak wrote: An overview of the new features can be found here: http://wiki.lyx.org/LyX/NewInLyX23 AFAICR, the new shell-escape [+minted] support made it to the 2.3, but it's not mentioned (yet). T.
LyX version 2.3.0 (beta 1)
Public release of LyX version 2.3.0beta1 We are proud to announce the first public beta of the new LyX 2.3 series. This pre-release is meant for testing and should not be used for serious work. For curious users who would like to test in order to help catch bugs before the 2.3.0 release, please back up all of your documents and be prepared for the worst to happen. Most users (who desire a stable LyX version) should not use this pre-release. The 2.3 series has a rich set of new features compared to the current stable series. An overview of the new features can be found here: http://wiki.lyx.org/LyX/NewInLyX23 You can download LyX 2.3.0beta1 from ftp://ftp.lyx.org/pub/lyx/devel/. We appreciate your help in testing this pre-release! The file lib/RELEASE-NOTES lists some known issues and problems compared to the current stable releases (LyX 2.2.x). We strongly recommend that packagers of LyX on various platforms and distributions read this file. As with any major release, this one comes with a lot of new features but also some bugs. If you think you have found a bug in LyX 2.3.0beta1, either email the LyX developers' mailing list (lyx-devel at lists.lyx.org), or open a bug report at https://www.lyx.org/trac/wiki/BugTrackerHome. Please specify if the behavior you are reporting is different from behavior in a previous LyX version. If you have trouble using LyX or have a question, consult the documentation that comes with LyX (under Help) and the LyX wiki, which you will find at https://wiki.lyx.org/. You can also send email to the LyX users' list (lyx-users at lists.lyx.org). The LyX team. https://www.lyx.org signature.asc Description: PGP signature
Re: 2.2.0 beta 1: Xetex not working
On 2016-02-11, Jürgen Lange wrote: > The PDF Producer changed from Xetex 0.2 in 2.1.4. to MikTex-xdvipdfmx > (20150315) in 2.2.0beta1. This is rather due to an MikTex update. xdvipdfmx is the part of XeTeX that transforms the intermediate format (XDVI) to PDF. Günter
Re: 2.2.0 beta 1: Xetex not working
Jürgen Lange wrote: > Hello, > thank you very much for 2.2.0 beta 1. > Compiling one of my documents does not work anymore in 2.2.0 beta 1. The > format is PDF (XeTeX). > The error-message is: > Kann keinen Latex Befehl für das Zeichen ḫ (Code-Punkt 0x1e2b) finden. > Einige Zeichen Ihres Dokuments sind mit der gewählten Kodierung > wahrscheinlich nicht darstellbar. > Eine Änderung der Dokumentkodierung auf 'utf8' könnte helfen. > Changing the document's encoding from default doesn't solve the problem. I > hope this can be fixed by modifying the Preferences. XeTeX compiles the > document fine with 2.1.4. Please double check whether the PDF produced by 2.1.4 is correct. 0x1e2b is LATIN SMALL LETTER H WITH BREVE BELOW (ḫ). Does it show up in the PDF produced by 2.1.4? Does it have the breve below? The error reporting for running LaTeX has been improved in 2.2.0. Older versions did sometimes ignore errors. Therefore it is quite likely that the error did already exist in 2.1.4, but it went unnoticed. If the PDF produced by 2.1.4 is correct please file a bug report at http://www.lyx.org/trac/wiki/BugTrackerHome and attach a minimal test case as .lyx file. Georg
2.2.0 beta 1: Xetex not working
The PDF Producer changed from Xetex 0.2 in 2.1.4. to MikTex-xdvipdfmx (20150315) in 2.2.0beta1.
2.2.0 beta 1: Xetex not working
Hello, thank you very much for 2.2.0 beta 1. Compiling one of my documents does not work anymore in 2.2.0 beta 1. The format is PDF (XeTeX). The error-message is: Kann keinen Latex Befehl für das Zeichen ḫ (Code-Punkt 0x1e2b) finden. Einige Zeichen Ihres Dokuments sind mit der gewählten Kodierung wahrscheinlich nicht darstellbar. Eine Änderung der Dokumentkodierung auf 'utf8' könnte helfen. Changing the document's encoding from default doesn't solve the problem. I hope this can be fixed by modifying the Preferences. XeTeX compiles the document fine with 2.1.4. (OS: Win10) Thanks Jürgen
Re: ANNOUNCE: LyX version 2.1.0 (beta 1)
Dear all, On Wed, Jul 31, 2013 at 5:22 PM, Vincent van Ravesteijn wrote: > Public release of LyX version 2.1.0beta1 > > Ubuntu binaries are now available on the Development PPA: https://launchpad.net/~lyx-devel/+archive/daily . Install 'lyx2.1pre - 2.1.0~beta1' to install the beta. The packaging should work just like for lyx2.0 and lyx2.1 packages, namely the installation of the beta should be independent of the main LyX installation (or any other LyX installation from the development PPA). Please let me know if you find any issues (or not) with the packaging set-up. Regards, Liviu
Libertine support LyX version 2.1.0 (beta 1)
The latest version of libertine in MacTeX 2013 (updated with tlmgr)
lacks the file libertineMono-type1.sty.
I took libertineRoman-type1.sty, modified it accordingly, put it into my
local tree, texhashed, reconfigured LyX and it works.
Cool.
el
On 2013-08-01 10:40 , Dr Eberhard Lisse wrote:
> Vincent,
>
> on a current 10.8.4 moving from 2.0.6 to yesterday's 2.1.0beta1
> how do I get libertine's Mono font installed?
>
> These are the result of
>
> grep -i libertine ~/Library/Application Support/LyX-2.1
>
> styFiles.lst:/usr/local/texlive/2013basic/texmf-dist/tex/latex/libertine/biolinum-type1.sty
> styFiles.lst:/usr/local/texlive/2013basic/texmf-dist/tex/latex/libertine/biolinum.sty
> styFiles.lst:/usr/local/texlive/2013basic/texmf-dist/tex/latex/libertine/libertine-type1.sty
> styFiles.lst:/usr/local/texlive/2013basic/texmf-dist/tex/latex/libertine/libertine.sty
> styFiles.lst:/usr/local/texlive/2013basic/texmf-dist/tex/latex/libertine/libertineMono.sty
> styFiles.lst:/usr/local/texlive/2013basic/texmf-dist/tex/latex/libertine/libertineotf.sty
> styFiles.lst:/usr/local/texlive/2013basic/texmf-dist/tex/latex/libertine/libertineRoman.sty
>
> but on the reconfigure it displays only libertine and biolinum, not the
> mono.
>
> If I add the plain
>
> \includepackage{libertine}
>
> in the preamble it continues to work.
>
> greetings, el
>
>
>
ANNOUNCE: LyX version 2.1.0 (beta 1)
Public release of LyX version 2.1.0beta1 We are proud to announce the first public beta release of the new LyX 2.1 series. LyX 2.1.0beta1 is the culmination of two and half years of hard work. This release is meant for testing before we actually release LyX 2.1. An overview of the new features can be found here: http://wiki.lyx.org/LyX/NewInLyX21 You can download LyX 2.1.0beta1 from ftp://ftp.lyx.org/pub/lyx/devel/lyx-2.1/lyx-2.1.0beta1/. We hope you will enjoy the result! The file RELEASE-NOTES lists some known issues and problems compared to the current stable releases (LyX 2.0.x). We strongly recommend that packagers of LyX on various platforms and distributions read this file. As with any major release, this one comes with lot of new features but also some bugs. If you think you have found a bug in LyX 2.1.0beta1, either email the LyX developers' mailing list (lyx-devel at lists.lyx.org), or open a bug report at http://www.lyx.org/trac/wiki/BugTrackerHome. If you have trouble using LyX or have a question, consult the documentation that comes with LyX (under Help) and the LyX wiki, which you will find at http://wiki.lyx.org/. You can also send email to the LyX users' list (lyx-users at lists.lyx.org). NOTE 1 (for Autotools users): "make check/distcheck" still fails for this beta release. This means that therewill be difficulties to install on platforms that require these checks to passbefore installing. NOTE 2 (for Linux/CMake users): If some of the dependencies of the test suite are not satisfied, CMake might not be able to generate the project files. To fix this problem, remove the following line from "CMakeLists.txt": add_subdirectory(development/autotests "/autotests") The LyX team. http://www.lyx.org
Re: LyX 2.1 beta 1: due in two weeks
Vincent van Ravesteijn wrote: > Development of new features and/or fixes that can wait for LyX 2.1.x, or > 2.2.0, can take place in the new features repository. IMHO it would be very good to concentrate on 2.1.0 and not to work on 2.2 or 2.1.x stuff at all until 2.1.0 is released. Otherwise it will be very difficult to do a timely release. > Please let me know if you have any remarks. What is the status of the bugs targeted to 2.1.0? Is the current list OK, or do we still need to postpone some? Georg
Re: LyX 2.1 beta 1: due in two weeks
On May 22, 2013, at 2:06 AM, Jean-Marc Lasgouttes wrote: > 22/05/2013 10:15, Vincent van Ravesteijn: >> Op 22-5-2013 9:29, Jerry schreef: >>> >>> The recent work to correct slow scrolling is not included? >>> Jerry >> >> I'm not sure I know which work you mean. Besides, is this really a new >> feature or just a bugfix ? > > I guess this is the patch from pdv we discussed in Milano. > > Jerry, unfortunately this patch cannot go in in its present form and we did > not find the time to do the cleanup in Milano. Too much time was spent at the > meeting debating the virtues of C++11, cmake or Qt instead of coding :-| > > This is difficult stuff and has to be done carefully. > > JMarc I appreciate that. Thanks for the update. Jerry
Re: LyX 2.1 beta 1: due in two weeks
Am 21.05.2013 10:32, schrieb Vincent van Ravesteijn: Please have a look at "http://wiki.lyx.org/LyX/NewInLyX21"; and help to complete the list of new features as much as possible. Maybe Uwe would also appreciate some help to document the new features. Please don't add anything to the UserGuide from now on. The UserGuide revision is ready and the translators will start their work. After that I start to update th docs for LyX 2.1. You help me the most if you mention all new features in http://wiki.lyx.org/LyX/NewInLyX21. thanks and regards Uwe
Re: LyX 2.1 beta 1: due in two weeks
22/05/2013 10:15, Vincent van Ravesteijn: Op 22-5-2013 9:29, Jerry schreef: The recent work to correct slow scrolling is not included? Jerry I'm not sure I know which work you mean. Besides, is this really a new feature or just a bugfix ? I guess this is the patch from pdv we discussed in Milano. Jerry, unfortunately this patch cannot go in in its present form and we did not find the time to do the cleanup in Milano. Too much time was spent at the meeting debating the virtues of C++11, cmake or Qt instead of coding :-| This is difficult stuff and has to be done carefully. JMarc
Re: LyX 2.1 beta 1: due in two weeks
Op 22-5-2013 9:29, Jerry schreef: The recent work to correct slow scrolling is not included? Jerry I'm not sure I know which work you mean. Besides, is this really a new feature or just a bugfix ? Vincent
Re: LyX 2.1 beta 1: due in two weeks
On May 21, 2013, at 1:32 AM, Vincent van Ravesteijn wrote: > Dear all, > > It seems that the current master has survived the Lyx Developer's Meeting and > is still in good shape. Therefore, I intend to release the first beta of LyX > 2.1 during the first weekend of June. In the meantime, the last topics can be > finished, the documentation can be updated, the translations can be updated, > and the release can be prepared. > > From now on, I would like to freeze the current master and to only allow: > - important bugfixes, and > - a few remaining topics that are 'in flight' > (I will send a separate mail about which topics I know that are being > prepared for LyX2.1) > > Development of new features and/or fixes that can wait for LyX 2.1.x, or > 2.2.0, can take place in the new features repository. > > Please have a look at "http://wiki.lyx.org/LyX/NewInLyX21"; and help to > complete the list of new features as much as possible. Maybe Uwe would also > appreciate some help to document the new features. The recent work to correct slow scrolling is not included? Jerry > > Depending on the feedback we get about this beta release, I will decide on > whether there will be more betas, or we will jump to the final LyX 2.1 > release. > > Please let me know if you have any remarks. > > Vincent > >
Re: LyX 2.1 beta 1: due in two weeks
Vincent van Ravesteijn wrote: > > Also if you are heading towards final freezing it would be nicer if we know > > the time schedule sooner than 2 weeks ahead. > > > Yes, a nice schedule is always better. On the other hand, if people do have > new features that they definitely want to have in 2.1, they should have > communicate about it in an earlier stage when I asked for it, or they > should make sure they finish it on a two weeks notice. I asked a few months > ago what features people wanted to get in, and I'm still waiting for those > features to get ready. I can't ask again now, and wait until all new > features that are proposed now will be ready, and then ask again... etc. No, don't worry I don't ask about new features, but there might be different things people have in mind to do before release is out (like the translations or similar) and this can take some time. > > > (I will send a separate mail about which topics I know that are being > > > prepared for LyX2.1) > > > > I plan to finish the cleanup of includes in our headers/cpp files. > > > > Is there any urgency to do this before 2.1 release ? Once I started I will finish it ;) It's true I haven't announced it but you haven't hinted time of freeze either so please bear with me. It would be helpful if you are more talkative about your plans and schedule. Pavel
Re: LyX 2.1 beta 1: due in two weeks
On Tue, May 21, 2013 at 11:12 AM, Pavel Sanda wrote: > Vincent van Ravesteijn wrote: > > (I will send a separate mail about which topics I know that are being > > prepared for LyX2.1) > > I plan to finish the cleanup of includes in our headers/cpp files. > Is there any urgency to do this before 2.1 release ? Vincent
Re: LyX 2.1 beta 1: due in two weeks
On Tue, May 21, 2013 at 11:12 AM, Pavel Sanda wrote: > Vincent van Ravesteijn wrote: > > (I will send a separate mail about which topics I know that are being > > prepared for LyX2.1) > > I plan to finish the cleanup of includes in our headers/cpp files. > > Next thing I would like to do after string freeze is to go through all new > strings and check their correctness, shouldn't be much disruptive, but > might > need one more release iteration for translators. > > > Depending on the feedback we get about this beta release, I will decide > on > > whether there will be more betas, or we will jump to the final LyX 2.1 > > release. > > > > Please let me know if you have any remarks. > > > I didn't get whether by "jump to the final LyX 2.1" you mean release > candidate > or 2.1 release. What I have seen in previous final releases is that you > need > more iterations not just because of bugs but to let packagers fix *their* > issues, so just single beta and final release is not good idea in case you > meant it. > There must be a reason to release intermediate versions. If packagers have problems, this could be one of the reasons. > > Also if you are heading towards final freezing it would be nicer if we know > the time schedule sooner than 2 weeks ahead. > > Yes, a nice schedule is always better. On the other hand, if people do have new features that they definitely want to have in 2.1, they should have communicate about it in an earlier stage when I asked for it, or they should make sure they finish it on a two weeks notice. I asked a few months ago what features people wanted to get in, and I'm still waiting for those features to get ready. I can't ask again now, and wait until all new features that are proposed now will be ready, and then ask again... etc. Vincent
Re: LyX 2.1 beta 1: due in two weeks
Vincent van Ravesteijn wrote: > (I will send a separate mail about which topics I know that are being > prepared for LyX2.1) I plan to finish the cleanup of includes in our headers/cpp files. Next thing I would like to do after string freeze is to go through all new strings and check their correctness, shouldn't be much disruptive, but might need one more release iteration for translators. > Depending on the feedback we get about this beta release, I will decide on > whether there will be more betas, or we will jump to the final LyX 2.1 > release. > > Please let me know if you have any remarks. I didn't get whether by "jump to the final LyX 2.1" you mean release candidate or 2.1 release. What I have seen in previous final releases is that you need more iterations not just because of bugs but to let packagers fix *their* issues, so just single beta and final release is not good idea in case you meant it. Also if you are heading towards final freezing it would be nicer if we know the time schedule sooner than 2 weeks ahead. Pavel
LyX 2.1 beta 1: due in two weeks
Dear all, It seems that the current master has survived the Lyx Developer's Meeting and is still in good shape. Therefore, I intend to release the first beta of LyX 2.1 during the first weekend of June. In the meantime, the last topics can be finished, the documentation can be updated, the translations can be updated, and the release can be prepared. From now on, I would like to freeze the current master and to only allow: - important bugfixes, and - a few remaining topics that are 'in flight' (I will send a separate mail about which topics I know that are being prepared for LyX2.1) Development of new features and/or fixes that can wait for LyX 2.1.x, or 2.2.0, can take place in the new features repository. Please have a look at "http://wiki.lyx.org/LyX/NewInLyX21"; and help to complete the list of new features as much as possible. Maybe Uwe would also appreciate some help to document the new features. Depending on the feedback we get about this beta release, I will decide on whether there will be more betas, or we will jump to the final LyX 2.1 release. Please let me know if you have any remarks. Vincent
win installer for 2.0.0 beta 1 ??
> would you please prepare a windows installer for the new beta release > 2.0.0 beta 2. I'm wondering that people are so curious to test each and every brand-new development release immediately. Anyway, here it is: http://developer.berlios.de/project/showfiles.php?group_id=5117&release_id=18138 regards Uwe
Re: win installer for 2.0.0 beta 1 ??
go2tob...@gmx.de wrote: > Maybe it is the normal workflow, to prepare for linux and after 3 weeks > have finished for windows? Or du you just have to push the green button > ? :-) the guys who are preparing installers are busy elsewhere outside lyx project. so unless you want to step in for creating installer yourself there nothing else to do than to wait ;) pavel
win installer for 2.0.0 beta 1 ??
Dear Lyx-developers, would you please prepare a windows installer for the new beta release 2.0.0 beta 2. I have no clue, if it is a lot of work to do this? Maybe it is the normal workflow, to prepare for linux and after 3 weeks have finished for windows? Or du you just have to push the green button ? :-) Thanks for your help. Tobias
Autosave not working in Beta-1
Since the introduction of threaded export, the autosave function didn't work anymore. I fixed this in r36324-r36328. Vincent
Re: compilation of lyx 2 beta 1 destroyed my linux (solved)
On Mon, 15 Nov 2010 05:27:12 -0800 (PST) >> "Marcelo" == Marcelo Acuña wrote: Marcelo> My excuses by the false alarm. I am very ashamed for that reason. No problem. It happens to everyone...we are just curios what has happened with your cat? ;) Sincerely, Gour -- Gour | Hlapicina, Croatia | GPG key: CDBF17CA signature.asc Description: PGP signature
Re: compilation of lyx 2 beta 1 destroyed my linux (solved)
> > During the course of the compilation it appeared a >> message of error: segment violation. > the only case i have seen such strange messages during > compilation of anything was > when my memory chipset got subverted. so maybe time to run > memory check tests... > > the only other way i'm aware how to hung up system in > compilation of lyx is to > switch the monolithic builds on, possibly with debug > symbols on _and_ not to have > at least gigabyte of free RAM. then you got swap hell for > few hours, without > possibility to stop it, except reboot. > > pavel You are right. Mother board has failed. Now also I have the probable explanation of because two pen-drives has been damaged in one week. My excuses by the false alarm. I am very ashamed for that reason. Marcelo
Re: compilation of lyx 2 beta 1 destroyed my linux
Am 15.11.2010 um 13:20 schrieb Gour: > On Mon, 15 Nov 2010 04:15:39 -0800 (PST) >>>>>>> "Marcelo" == Marcelo Acuña wrote: > > Marcelo> This morning I configured lyx beta 1 and start the compilation. > Marcelo> During the course of the compilation it appeared a message of > Marcelo> error: segment violation. It was trying to read the error > Marcelo> message when I noticed that the computer was hung. I reset it > Marcelo> and now, during the starting, shows an error as if it did not > Marcelo> have installed operating system. I have debian lenny 5.0.5, > Marcelo> for amd64. > > Did it eat your cat as well? More seriously... you have a hardware problem. Check your computer components, e. g. with a linux installation disc. I'd guess either the hard disk died or some main board component is malfunctioning. The latter may result in a corrupted hard disk... Nevertheless the subject line of your e-mail is funny. But I can understand that you are not happy about that. Stephan
Re: compilation of lyx 2 beta 1 destroyed my linux
Marcelo Acu?a wrote: > This morning I configured lyx beta 1 and start the compilation. > During the course of the compilation it appeared a message of error: segment > violation. the only case i have seen such strange messages during compilation of anything was when my memory chipset got subverted. so maybe time to run memory check tests... the only other way i'm aware how to hung up system in compilation of lyx is to switch the monolithic builds on, possibly with debug symbols on _and_ not to have at least gigabyte of free RAM. then you got swap hell for few hours, without possibility to stop it, except reboot. pavel
Re: compilation of lyx 2 beta 1 destroyed my linux
On Mon, 15 Nov 2010 04:15:39 -0800 (PST) >>>>>> "Marcelo" == Marcelo Acuña wrote: Marcelo> This morning I configured lyx beta 1 and start the compilation. Marcelo> During the course of the compilation it appeared a message of Marcelo> error: segment violation. It was trying to read the error Marcelo> message when I noticed that the computer was hung. I reset it Marcelo> and now, during the starting, shows an error as if it did not Marcelo> have installed operating system. I have debian lenny 5.0.5, Marcelo> for amd64. Did it eat your cat as well? :-D Sincerely, Gour -- Gour | Hlapicina, Croatia | GPG key: CDBF17CA signature.asc Description: PGP signature
compilation of lyx 2 beta 1 destroyed my linux
This morning I configured lyx beta 1 and start the compilation. During the course of the compilation it appeared a message of error: segment violation. It was trying to read the error message when I noticed that the computer was hung. I reset it and now, during the starting, shows an error as if it did not have installed operating system. I have debian lenny 5.0.5, for amd64. Marcelo
Re: instructions for upgrade from LyX 1.6.7 to 2.0 beta 1?
Am 11.11.2010 um 07:42 schrieb Justin Wood: > Hi gang. As LyX 2.0 beta 1 is now released, I thought I'd make the switch > over (OS X 10.6). Hi Justin, good to have brave users who are going to test beta release of LyX 2.0. But it's beta and not clear exactly when the release will happen. So I hope, you're using it with copies of your important documents. > It installs and runs fine, but as best I can tell there is no automated > import of LyX 1.6.7 settings. Yes, the automated import is on the agenda only. The needed scripts are unfinished or at least the integration of them. > Are there any (draft) instructions available for walking the upgrade path? > Are there any backwards compatibility issues or conflicts to watch out for, > or can the existing LyX-1.6 user directory pretty much just be copied across? Yes, there are backwards compatibility issues. I never did copy the user directory and the plan is to make the transition with the help of converter scripts. > Ditto for migrating actual documents. That is done automatically and should work. After saving the documents they'll have the new 2.0 format. In the near future LyX 1.6 will be able to read LyX 2.0 documents. That's not the case already. So, as said above, you should start with copies of your documents since there is no easy way to go back. > Thanks! And very much looking forward to using this shiny new creature. Have fun. Stephan
ANNOUNCE: LyX version 2.0.0 (beta 1)
Pre-release of LyX version 2.0.0 (beta 1) == We are pleased to announce the first public pre-release of LyX 2.0.0. Development moved to the beta phase which basically means we will no more include new features and focus on polishing the current ones. We are thus grateful for any feedback you sent us regarding the bugs you encounter while testing the beta release. Except trying new features this is also good time to check that your favorite old files works with the new release as expected. Please note that this release is for testing purposes only, users are encouraged to use current 1.6 stable release for any serious work. Tarballs can be found at ftp://ftp.lyx.org/pub/lyx/devel/ and binaries should follow soon. LyX 2.0.0 will be culmination of more than two years of hard work and you can find an overview of the new features here: http://wiki.lyx.org/LyX/NewInLyX20 If you think you found a bug in LyX 2.0.0, either e-mail the LyX developers' mailing list (lyx-devel at lists.lyx.org), or open a bug report at http://www.lyx.org/trac/wiki/BugTrackerHome If you have trouble using LyX or have a question, consult the documentation that comes with LyX and http://wiki.lyx.org. If you can't find the answer there, e-mail the LyX users' list (lyx-users at lists.lyx.org). We hope you will enjoy the result! The LyX team. http://www.lyx.org
Re: Request to test beta 1
José Matos wrote: Hi, temporarily I have placed the source for lyx-1.6.0beta1 in http://lyx.org/~jamatos/lyx-1.6/ If it goes well we could/should announce it publically and then it would be nice to have packages to test this under different scenarios. If the sources have some unseen problem I would like to fix those issues as soon as possible and then release the second beta immediately. Regards, FWIW, seems to be working fine for me (linux, qt 4.2.1). I do get the message "unknown Inset type 'Space'", though... Dov
Re: Request to test beta 1
On Sat, May 31, 2008 at 2:00 AM, José Matos <[EMAIL PROTECTED]> wrote: > On Saturday 31 May 2008 02:35:36 Bennett Helm wrote: > > > > This works for me. Thanks. > > > > Should we create the Mac binaries off of this? (The splash screen reads > > 1.6.0svn.) > > If that is the case them lets us wait until Monday where I will tag a new > beta2 and where this problem is fixed. OK? OK -- will do Bennett
Re: Custom compiler flags not used for LinkBack [Was: Request to test beta 1]
Konrad Hofbauer wrote: For cross-compiling PPC-Binaries on an Intel-Mac (which Bennett and me need to do to create universal binaries for release), I need to set export CFLAGS="-arch ppc" export CXXFLAGS="-arch ppc" export LDFLAGS="$LDFLAGS -arch ppc" and they automatically get passed to g++, libtool, etc. (and worked fine for 1.5.5). It still works for 1.6beta1, EXCEPT for the LinkBack part, where for one or the other reason the above flags are not put in. The (for most people but me probably obvious) solution is: We also need to set CPPFLAGS, since LinkBack is written in Objectiv-C and not C++. /Konrad
Re: Request to test beta 1
On Saturday 31 May 2008 02:35:36 Bennett Helm wrote: > > This works for me. Thanks. > > Should we create the Mac binaries off of this? (The splash screen reads > 1.6.0svn.) If that is the case them lets us wait until Monday where I will tag a new beta2 and where this problem is fixed. OK? > Bennett -- José Abílio
Re: Request to test beta 1
On Fri, May 30, 2008 at 7:58 PM, Pavel Sanda <[EMAIL PROTECTED]> wrote: > Pavel Sanda wrote: > > > I can't compile on Mac; I get: > > > > > > Making all in po > > > make LyX-1.6.pot-update > > > make[2]: *** No rule to make target `../src/client/debug.cpp', needed > by > > > `LyX-1.6.pot-update'. Stop. > > > make[1]: *** [LyX-1.6.pot] Error 2 > > > make: *** [all-recursive] Error 1 > > these should be ok now. can you try this tarball?: > 195.113.26.193/~sanda/junk/lyx-1.6.0svn.tar.bz2 This works for me. Thanks. Should we create the Mac binaries off of this? (The splash screen reads 1.6.0svn.) Bennett
Custom compiler flags not used for LinkBack [Was: Request to test beta 1]
For cross-compiling PPC-Binaries on an Intel-Mac (which Bennett and me need to do to create universal binaries for release), I need to set export CFLAGS="-arch ppc" export CXXFLAGS="-arch ppc" export LDFLAGS="$LDFLAGS -arch ppc" and they automatically get passed to g++, libtool, etc. (and worked fine for 1.5.5). It still works for 1.6beta1, EXCEPT for the LinkBack part, where for one or the other reason the above flags are not put it: /bin/sh ../../libtool --mode=compile gcc -DHAVE_CONFIG_H -I. -I../../src -I./.. -I../../boost -DQT_NO_STL -DQT_NO_KEYWORDS -I/Users/khofbaue/lyxdevel2/qt-4.4.0-install/include -I/Users/khofbaue/lyxdevel2/qt-4.4.0-install/include/QtCore -Wextra -Wall -I/System/Library/Frameworks/CoreFoundation.framework/Headers -g -O2 -MT LinkBack.lo -MD -MP -MF .deps/LinkBack.Tpo -c -o LinkBack.lo `test -f 'linkback/LinkBack.m' || echo './'`linkback/LinkBack.m gcc -DHAVE_CONFIG_H -I. -I../../src -I./.. -I../../boost -DQT_NO_STL -DQT_NO_KEYWORDS -I/Users/khofbaue/lyxdevel2/qt-4.4.0-install/include -I/Users/khofbaue/lyxdevel2/qt-4.4.0-install/include/QtCore -Wextra -Wall -I/System/Library/Frameworks/CoreFoundation.framework/Headers -g -O2 -MT LinkBack.lo -MD -MP -MF .deps/LinkBack.Tpo -c linkback/LinkBack.m -o LinkBack.o There is no "-arch ppc", but there needs to be one. Without it, this part is compiled to the i686 machine format (while everything else is in ppc), which later results in the following error (because it tries to mix ppc and intel code).: ranlib: archive member: .libs/liblyxsupport.a(LinkBack.o) cputype (7) does not match previous archive members cputype (18) (all members must match) I see that the compiler calls for the LinkBack-Files are slightly different to all the rest, but I do not quite understand that stuff. Why is this happening, what sets LinkBack apart from the rest? How do I pass the above flags also to the part where LinkBack is compiled? Any hint appreciated! Thanks a lot, Konrad
Re: Request to test beta 1
Pavel Sanda wrote: > > I can't compile on Mac; I get: > > > > Making all in po > > make LyX-1.6.pot-update > > make[2]: *** No rule to make target `../src/client/debug.cpp', needed by > > `LyX-1.6.pot-update'. Stop. > > make[1]: *** [LyX-1.6.pot] Error 2 > > make: *** [all-recursive] Error 1 these should be ok now. can you try this tarball?: 195.113.26.193/~sanda/junk/lyx-1.6.0svn.tar.bz2 > yep, you gave me a hint. i may be know how to sanitize make distcheck. unfortunately there are other problems there. > pavel
Re: Request to test beta 1
rgheck wrote: Konrad Hofbauer wrote: Bennett Helm wrote: make[2]: *** No rule to make target `../src/client/debug.cpp', needed by `LyX-1.6.pot-update'. Stop. Try removing src/client/debug.cpp from POTFILES.in. I'm not sure what the right fix is at the dist level, but that ought to do it. This works. /Konrad
Re: Request to test beta 1
> I can't compile on Mac; I get: > > Making all in po > make LyX-1.6.pot-update > make[2]: *** No rule to make target `../src/client/debug.cpp', needed by > `LyX-1.6.pot-update'. Stop. > make[1]: *** [LyX-1.6.pot] Error 2 > make: *** [all-recursive] Error 1 yep, you gave me a hint. i may be know how to sanitize make distcheck. pavel
Re: Request to test beta 1
Konrad Hofbauer wrote: Bennett Helm wrote: I can't compile on Mac; I get: Making all in po make LyX-1.6.pot-update make[2]: *** No rule to make target `../src/client/debug.cpp', needed by `LyX-1.6.pot-update'. Stop. make[1]: *** [LyX-1.6.pot] Error 2 make: *** [all-recursive] Error 1 Exactly same here (Intel-Mac on 10.4). There is no such file "../src/client/debug.cpp" in the extracted archive, the only debug.cpp I have is in "../src/support/debug.cpp" I copied debug.cpp and debug.h from ../src/support to ../src/client, and then it built successfully (and also compiled the UserGuide). I cannot judge if this is the "proper" fix, but it helps here. Try removing src/client/debug.cpp from POTFILES.in. I'm not sure what the right fix is at the dist level, but that ought to do it. What puzzles me is why it doesn't fail here, since src/client/debug.cpp was removed a while ago. rh
Re: Lyx 1.6.0 Beta 1 => Betanews.com
Danny Ferrin wrote: Hi, I am a regular lyx user here, and I use it regularly at university, it's very helpful. I just wanted to congratulate you guys for all the excellent work you've done with this program, it's a pure gem. Meanwhile, I would like to make a suggestion. For the beta 1 of Lyx 1.6.0, would it be possible to post it on www.betanews.com . I think it would be a great idea because this is a famous site, and the word will spread out even more about Lyx. My 2 cents. Have a great day, Danny Ferrin It looks as though YOU could submit, via the Submit News link. Doing so would be helpful---once beta 1 is actually out. rh
Lyx 1.6.0 Beta 1 => Betanews.com
Hi, I am a regular lyx user here, and I use it regularly at university, it's very helpful. I just wanted to congratulate you guys for all the excellent work you've done with this program, it's a pure gem. Meanwhile, I would like to make a suggestion. For the beta 1 of Lyx 1.6.0, would it be possible to post it on www.betanews.com . I think it would be a great idea because this is a famous site, and the word will spread out even more about Lyx. My 2 cents. Have a great day, Danny Ferrin
Re: Request to test beta 1
Bennett Helm wrote: I can't compile on Mac; I get: Making all in po make LyX-1.6.pot-update make[2]: *** No rule to make target `../src/client/debug.cpp', needed by `LyX-1.6.pot-update'. Stop. make[1]: *** [LyX-1.6.pot] Error 2 make: *** [all-recursive] Error 1 Exactly same here (Intel-Mac on 10.4). There is no such file "../src/client/debug.cpp" in the extracted archive, the only debug.cpp I have is in "../src/support/debug.cpp" I copied debug.cpp and debug.h from ../src/support to ../src/client, and then it built successfully (and also compiled the UserGuide). I cannot judge if this is the "proper" fix, but it helps here. /Konrad
Re: Request to test beta 1
On Friday 30 May 2008 19:08:01 rgheck wrote: > I think your platform is very similar to mine, but for what it's worth: > it compiles fine here: Fedora 8, etc. FWIW I have used to test both F9 and what will be F10 (rawhide). > rh -- José Abílio
Re: Request to test beta 1
José Matos wrote: Hi, temporarily I have placed the source for lyx-1.6.0beta1 in http://lyx.org/~jamatos/lyx-1.6/ If it goes well we could/should announce it publically and then it would be nice to have packages to test this under different scenarios. If the sources have some unseen problem I would like to fix those issues as soon as possible and then release the second beta immediately. I think your platform is very similar to mine, but for what it's worth: it compiles fine here: Fedora 8, etc. rh
Re: Request to test beta 1
On Friday 30 May 2008 18:09:48 Bennett Helm wrote: > On Fri, May 30, 2008 at 12:15 PM, José Matos <[EMAIL PROTECTED]> wrote: > > Hi, > >temporarily I have placed the source for lyx-1.6.0beta1 in > > http://lyx.org/~jamatos/lyx-1.6/ > > I needed to use: http://www.lyx.org/~jamatos/lyx-1.6/ OK, this is probably due to the re-routing rules used in the new site. >If it goes well we could/should announce it publically and then it > > > would be > > nice to have packages to test this under different scenarios. If the > > sources > > have some unseen problem I would like to fix those issues as soon as > > possible > > and then release the second beta immediately. > > I can't compile on Mac; I get: > > Making all in po > make LyX-1.6.pot-update > make[2]: *** No rule to make target `../src/client/debug.cpp', needed by > `LyX-1.6.pot-update'. Stop. > make[1]: *** [LyX-1.6.pot] Error 2 > make: *** [all-recursive] Error 1 No such problem here. :-( > Also, I'm not sure if this matters, but when I tried running autogen.sh, I > get a bunch of warnings of this sort: > > configure.ac:168: warning: AC_CACHE_VAL(lt_prog_compiler_pic_works, ...): > suspicious cache-id, must contain _cv_ to be cached I got some of those too but I thought they were due to the new autoconf, and after they are only warnings... (famous last words). > Bennett -- José Abílio
Re: Request to test beta 1
On Fri, May 30, 2008 at 12:15 PM, José Matos <[EMAIL PROTECTED]> wrote: > Hi, >temporarily I have placed the source for lyx-1.6.0beta1 in > http://lyx.org/~jamatos/lyx-1.6/ I needed to use: http://www.lyx.org/~jamatos/lyx-1.6/ If it goes well we could/should announce it publically and then it > would be > nice to have packages to test this under different scenarios. If the > sources > have some unseen problem I would like to fix those issues as soon as > possible > and then release the second beta immediately. I can't compile on Mac; I get: Making all in po make LyX-1.6.pot-update make[2]: *** No rule to make target `../src/client/debug.cpp', needed by `LyX-1.6.pot-update'. Stop. make[1]: *** [LyX-1.6.pot] Error 2 make: *** [all-recursive] Error 1 Also, I'm not sure if this matters, but when I tried running autogen.sh, I get a bunch of warnings of this sort: configure.ac:168: warning: AC_CACHE_VAL(lt_prog_compiler_pic_works, ...): suspicious cache-id, must contain _cv_ to be cached Bennett
Request to test beta 1
Hi, temporarily I have placed the source for lyx-1.6.0beta1 in http://lyx.org/~jamatos/lyx-1.6/ If it goes well we could/should announce it publically and then it would be nice to have packages to test this under different scenarios. If the sources have some unseen problem I would like to fix those issues as soon as possible and then release the second beta immediately. Regards, -- José Abílio
Please hold on any commits in trunk (tagging beta 1)
As the title says. -- José Abílio
Re: Beta 1 (day -1)
José Matos wrote: > On Wednesday 28 May 2008 10:38:06 José Matos wrote: > The DNS goes crazy: > $ svn up > ssh: Could not resolve hostname svn.lyx.org: Name or service not known > svn: Connection closed unexpectedly echo 62.70.27.115 svn.lyx.org >>/etc/hosts pavel
Re: Beta 1 (day -1)
On Wednesday 28 May 2008 10:38:06 José Matos wrote: > Hi, > this is a short note to assure you that I intend to release beta 1 > tomorrow. This begs for patches that don't disturb the flow (compiling and > running). If you have a huge patch please hold it on until after the > release. My modem keeps playing tricks with me. :-( The DNS goes crazy: $ svn up ssh: Could not resolve hostname svn.lyx.org: Name or service not known svn: Connection closed unexpectedly I will have to finish this procedure tomorrow. Argh :-( > Regards, -- José Abílio
Beta 1 (day -1)
Hi, this is a short note to assure you that I intend to release beta 1 tomorrow. This begs for patches that don't disturb the flow (compiling and running). If you have a huge patch please hold it on until after the release. Regards, -- José Abílio
Re: Beta 1 (preparation stage)
On Fri, May 23, 2008 at 04:01:19PM +0100, José Matos wrote: > I think that Abdel intended to send this message to the list and not just to > me. :-) > > Because I am somebody, not anybody. ;-) Anybody could have said that. Andre'
Re: Beta 1 (preparation stage)
José Matos wrote: On Friday 23 May 2008 13:11:33 you wrote: José Matos wrote: Hi all, I suggest to release beta 1 next Thursday, and from there to release a new beta every 3 weeks until we are ready to go RC. So from now on no major features are allowed. Comments? I think we should upgrade boost to 1.35 and make sure LyX compile and don't crash with it. Anybody knows how to upgade boost? Abdel. I think that Abdel intended to send this message to the list and not just to me. :-) Because I am somebody, not anybody. ;-) Right, I wouldn't dare to calling you anybody :-) Abdel.
Re: Beta 1 (preparation stage)
On Friday 23 May 2008 13:11:33 you wrote: > José Matos wrote: > > Hi all, > > I suggest to release beta 1 next Thursday, and from there to > > release a new beta every 3 weeks until we are ready to go RC. > > > > So from now on no major features are allowed. > > > > Comments? > > > > I think we should upgrade boost to 1.35 and make sure LyX compile and > don't crash with it. Anybody knows how to upgade boost? > > Abdel. I think that Abdel intended to send this message to the list and not just to me. :-) Because I am somebody, not anybody. ;-) -- José Abílio
Re: Beta 1 (preparation stage)
José Matos wrote: > On Friday 23 May 2008 11:40:03 Pavel Sanda wrote: > > old patch is here: > > http://bugzilla.lyx.org/attachment.cgi?id=2014&action=view > > If you have another developer to support this patch I am OK with it. :-) ok, i will write Tommasso to ask him if he wants to to finish it. > What needs to be done to finish the patch? it needs to be conformed to the new ui structure (Abdel has described it somewhere.) > The next question is, if everything goes wrong what is the contingency > plan? :-) we will vote social democratic party, which will save us. pavel
Re: Beta 1 (preparation stage)
On Friday 23 May 2008 11:40:03 Pavel Sanda wrote: > old patch is here: > http://bugzilla.lyx.org/attachment.cgi?id=2014&action=view If you have another developer to support this patch I am OK with it. :-) What needs to be done to finish the patch? The next question is, if everything goes wrong what is the contingency plan? :-) > pavel -- José Abílio
Re: Beta 1 (preparation stage)
José Matos wrote: > On Friday 23 May 2008 11:17:28 Pavel Sanda wrote: > > > > is search dialog major feature? > > Are the code changes restrict to a single place (or a small set of places)? old patch is here: http://bugzilla.lyx.org/attachment.cgi?id=2014&action=view pavel
Re: Beta 1 (preparation stage)
On Friday 23 May 2008 11:24:37 José Matos wrote: > Nope. This is very invasive and I look that this change would occur at the > begin of a development cycle. s/I look this change would occur/I would like this change to occur/ -- José Abílio
Re: Beta 1 (preparation stage)
José Matos wrote: > On Friday 23 May 2008 11:15:57 Jean-Marc Lasgouttes wrote: > > José Matos <[EMAIL PROTECTED]> writes: > > > So from now on no major features are allowed. > > > > No xml file format? > > Nope. This is very invasive are you sure? :)) pavel
