Re: [LyX/2.3.x] README.localization: document how to update layouttranslations under Win
Am Dienstag, 20. Februar 2018 22:35:42 CET schrieb Scott Kostyshak : > > If you need to manually regenerate the layouttranslations file from .po > > files> > > -run `make ../lib/layouttranslations' in the po directory. The Python > > polib > > -library is needed for building the output file. > > +- Under Linux: execute the command > > + `make ../lib/layouttranslations' > > (not a comment on the patch) > > Kornel, should we specify the CMake target on Linux here also? > > Scott I'm for it. The target (if it exist) is for all platforms (not only Linux). # make layouttranslations1 Kornel signature.asc Description: This is a digitally signed message part.
Re: Results of small poll - download speed of LyX installers & where we go from there
On Tue, Feb 20, 2018 at 8:28 PM, Scott Kostyshak wrote: > On Wed, Feb 21, 2018 at 02:17:33AM +, Joel Kulesza wrote: > > > Understood. I suppose one aspect of "emphasizing" that was veto'd was to > > include a note that the main download site is based in France. This > seems > > like an odd omission to me because all mirrors have their location listed > > and because the main download site's URL doesn't give an indication of > > location naturally (e.g., not a .fr or similar TLD). > > It seems irrelevant to me where the server is. The server could be in > the U.S. and just be very slow. Or, the server could be in France and > could work just fine for someone in the U.S. (as it works for me). True. However, my thought was that based on the poll, for every response that tested both the default and UCSD, UCSD was faster. Because no average speeds are posted (which is reasonable because of the large variation and unpredictability) and because locations are only posted for mirrors, if I experienced slow downloads from the main site there is nothing that would prompt me to try another thinking it was closer/faster/etc. other than curiosity. Were I to know the main download link is not physically near me versus another that is clearly so (and likely then taking fewer routing hops), I'd be more inclined to try a mirror if I experience slow speeds. Naturally, I'm making the case on account of others. I've adjusted my own behavior to pull from UCSD; however, it's not clear to me that new users would explore mirrors trying to optimize their retrieval. Further, I (perhaps unfairly) generally regard mirrors as a secondary option to the main site assuming that site will be fastest/most stable/auto-negotiated/etc. > What > is relevant is whether the server is fast enough for you, and you can > only see by trying it. True, but again, using distance as a surrogate to routing hops can give a clue, but that metric is only available if full information is given for all downloads sites, not just auxiliaries. > But if another developer gives a +1 for > specifying that the server is in France, I will listen. > > In any case, this discussion on server speeds is a good one to have and > I'm glad we collected a poll and made progress on making it better. > Thanks for all of the suggestions. > I'm also happy to have the discussion and hopefully to make it most clear to a new LyX user where they can most quickly obtain the program. Thanks, Joel
Running ctests on 2.3.x branch
Günter and Kornel (and anyone else), if you have the time, can you run the ctests on the 2.3.x branch? I will run them tomorrow, and we can compare our results and do one final check of whether there are any regressions. Thanks, Scott signature.asc Description: PGP signature
Re: Lost translators
On Tue, Feb 20, 2018 at 08:20:39AM +, Jürgen Spitzmüller wrote: > Am Dienstag, den 20.02.2018, 00:41 -0500 schrieb Scott Kostyshak: > > > Mark them as "inactive", as CTAN does for TeX package authors. > > > > To do this, we just append " (inactive)" to the name field, right? > > I'd say so, since the PO header does not have a specific category. > https://www.gnu.org/software/trans-coord/manual/gnun/html_node/PO-Heade > r.html OK I made the change to master at f66fa17c and 2.3.x at d2b65e27. Thanks, Scott signature.asc Description: PGP signature
Re: [LyX/2.3.x] README.localization: document how to update layouttranslations under Win
> If you need to manually regenerate the layouttranslations file from .po files > -run `make ../lib/layouttranslations' in the po directory. The Python polib > -library is needed for building the output file. > +- Under Linux: execute the command > + `make ../lib/layouttranslations' (not a comment on the patch) Kornel, should we specify the CMake target on Linux here also? Scott signature.asc Description: PGP signature
Re: New policy for 2.3.x branch
On Tue, Feb 20, 2018 at 09:33:41PM +, Kornel Benko wrote: > OK, then I propose to cherry-pick ed7cdff. It corrects the creation of > layouttranslations with cmake. Go ahead. Scott signature.asc Description: PGP signature
Re: New policy for 2.3.x branch
On Tue, Feb 20, 2018 at 09:27:24PM +, Uwe Stöhr wrote: > Am 20.02.2018 um 22:03 schrieb Scott Kostyshak: > > > even for documentation > > or changing comments or whitespace, be posted to the list explicitly > > saying why it should be included for 2.3.0. The only exceptions to this > > are po files and lib/layouttranslations. > > Hi Scott, > > I would like to allow also documentation changes that only affect a certain > language. For example Yesterday I got a ru.po update together with some > updated links in a Russian doc file. Makes sense, go ahead with these. Please discuss on the list if there are any substantial changes proposed (e.g. changes to the preamble or default output format). > I think such changes can go in unless the whole branch is frozen. I > mean our translators invest their time and could be disappointed that > some updates did make it to the final release. I just asked that everyone asks for explicit permission before committing anything. Scott signature.asc Description: PGP signature
Re: Fix Problem With Background Export Cancellation
On Wed, Feb 21, 2018 at 01:57:36AM +, Richard Heck wrote: > On 02/19/2018 11:30 PM, Scott Kostyshak wrote: > > On Tue, Feb 20, 2018 at 03:51:50AM +, Richard Heck wrote: > >> Please see attached patch. > > I will test this when I have time. Is there any known problem? The last > > time I tested, I just compiled the Embedded Objects manual and canceled > > it at various times (e.g. after 0.5 seconds, 1, second, 5 seconds). > > There were a lot of problems but this patch sounds like it addresses > > them. > > The only problem I know if is the one mentioned: Failure actually to > abort the export, as opposed just to whatever part of it is happening at > the moment. OK good to know. Scott signature.asc Description: PGP signature
Re: Results of small poll - download speed of LyX installers & where we go from there
On Wed, Feb 21, 2018 at 02:17:33AM +, Joel Kulesza wrote: > Understood. I suppose one aspect of "emphasizing" that was veto'd was to > include a note that the main download site is based in France. This seems > like an odd omission to me because all mirrors have their location listed > and because the main download site's URL doesn't give an indication of > location naturally (e.g., not a .fr or similar TLD). It seems irrelevant to me where the server is. The server could be in the U.S. and just be very slow. Or, the server could be in France and could work just fine for someone in the U.S. (as it works for me). What is relevant is whether the server is fast enough for you, and you can only see by trying it. But if another developer gives a +1 for specifying that the server is in France, I will listen. In any case, this discussion on server speeds is a good one to have and I'm glad we collected a poll and made progress on making it better. Thanks for all of the suggestions. Scott signature.asc Description: PGP signature
Re: Results of small poll - download speed of LyX installers & where we go from there
On Tue, Feb 20, 2018 at 6:43 AM, Pavel Sanda wrote: > Joel Kulesza wrote: > > What regions were those (I'm mostly curious)? US(NM) was one I know of, > > validated through the result provided. > > Asia/South America > Thanks; sorry I missed when you said this previously. > > What I'm attempting to get at is: do we need another > > download mechanism or do we need to refine/emphasize the message to > > downloaders that alternatives exist and they may in in fact be faster > than > > the default? > > We added sentence to both web and announce file. I do not think we should > do > more when it comes to "emphasizing". > Understood. I suppose one aspect of "emphasizing" that was veto'd was to include a note that the main download site is based in France. This seems like an odd omission to me because all mirrors have their location listed and because the main download site's URL doesn't give an indication of location naturally (e.g., not a .fr or similar TLD). As a "dumb American" I natively assumed that the main site was based somewhere in the continental US having had no clue to the contrary. Incidentally, it's surprising to me that the UCSD mirror often gave higher speeds to poll respondents than the main site. I wonder if that was a fluke or whether it might make a more suitable "primary" site (or maybe that doesn't work because of an agreement made with the host?). > > Along those lines, rather than spinning up a torrent, has > > anyone investigated what it would take to get an auto-negotiating mirror > > setup such that when someone downloads from the default site they are > > automagically redirected to the fastest available mirror? > > Actually I spent some time to look on alternatives before proceeding with > torrent way and it's painful. We could rely on 3rd parties, like > sourceforge, > but their reputation with adding adware to download pages in history is > not exactly stellar and it would still need additional maintence work. > I agree about SourceForge; I too am not a fan of their site and business practices. Partially I was wondering what the backend of LyX's website is; is it capable of dynamic hosting? Could some simple PHP/ASPX/etc. code be made to perform the auto-negotiation for the then-fastest mirror to then generate a link on the page that gets served...? > To sum up, I reached my threshold of time I was willing to spend on > the distributing issue and after dribbling with several variants > this (kind of fake) torrent showed up as best; wrote the script and > offered one-command solution without additional maintenance work. > Whether maintainers want to use it or no it's up them... Understood; my thanks for (a) your concern and (b) your work to improve on what's there!
Re: Fix Problem With Background Export Cancellation
On 02/19/2018 11:30 PM, Scott Kostyshak wrote: > On Tue, Feb 20, 2018 at 03:51:50AM +, Richard Heck wrote: >> Please see attached patch. > I will test this when I have time. Is there any known problem? The last > time I tested, I just compiled the Embedded Objects manual and canceled > it at various times (e.g. after 0.5 seconds, 1, second, 5 seconds). > There were a lot of problems but this patch sounds like it addresses > them. The only problem I know if is the one mentioned: Failure actually to abort the export, as opposed just to whatever part of it is happening at the moment. Richard
Re: New policy for 2.3.x branch
Am Dienstag, 20. Februar 2018 16:03:30 CET schrieb Scott Kostyshak : > Dear all, > > Do you have any planned commits to the 2.3.x branch before 2.3.0 is > released? What is the commit and by when are you prepared to commit it? > > I don't have anything on my radar and I just want to be aware of whether > anyone has something else they're working on that they think is a > candidate for 2.3.0. > > I would like to change the commit policy for the 2.3.x branch to be > that, starting Wednesday at 23:59 UTC, any patch, even for documentation > or changing comments or whitespace, be posted to the list explicitly > saying why it should be included for 2.3.0. The only exceptions to this > are po files and lib/layouttranslations. OK, then I propose to cherry-pick ed7cdff. It corrects the creation of layouttranslations with cmake. > Thanks, > > Scott Kornel signature.asc Description: This is a digitally signed message part.
Re: New policy for 2.3.x branch
Am 20.02.2018 um 22:03 schrieb Scott Kostyshak: even for documentation or changing comments or whitespace, be posted to the list explicitly saying why it should be included for 2.3.0. The only exceptions to this are po files and lib/layouttranslations. Hi Scott, I would like to allow also documentation changes that only affect a certain language. For example Yesterday I got a ru.po update together with some updated links in a Russian doc file. I think such changes can go in unless the whole branch is frozen. I mean our translators invest their time and could be disappointed that some updates did make it to the final release. regards Uwe
New policy for 2.3.x branch
Dear all, Do you have any planned commits to the 2.3.x branch before 2.3.0 is released? What is the commit and by when are you prepared to commit it? I don't have anything on my radar and I just want to be aware of whether anyone has something else they're working on that they think is a candidate for 2.3.0. I would like to change the commit policy for the 2.3.x branch to be that, starting Wednesday at 23:59 UTC, any patch, even for documentation or changing comments or whitespace, be posted to the list explicitly saying why it should be included for 2.3.0. The only exceptions to this are po files and lib/layouttranslations. Thanks, Scott signature.asc Description: PGP signature
Re: [LyX/2.3.x] layouttranslations and uk.po: corrections from Yuri
On Tue, Feb 20, 2018 at 08:12:26PM +, Uwe Stöhr wrote: > Am 20.02.2018 um 19:27 schrieb Scott Kostyshak: > > > Uwe, will you have time to fix this issue soon? > > it should be fixed now, please test. Thanks! Works well now. It runs without error, and no changes to layouttranslations are made (to check that everything is updated). So looks good to me. Thanks for your help with the translations. Scott signature.asc Description: PGP signature
Re: [LyX/2.3.x] layouttranslations and uk.po: corrections from Yuri
Am 20.02.2018 um 19:27 schrieb Scott Kostyshak: Uwe, will you have time to fix this issue soon? it should be fixed now, please test. regards Uwe
Re: [LyX/2.3.x] layouttranslations and uk.po: corrections from Yuri
> After deleting the offending character I see new changes in el & uk, which went uncommitted. I installed now the polib python extension and tried to generate layouttranslations. After removing the BOM I get this error: File "C:\Program Files (x86)\Python36-32\lib\encodings\cp1252.py", line 19, in encode return codecs.charmap_encode(input,self.errors,encoding_table)[0] UnicodeEncodeError: 'charmap' codec can't encode character '\ufeff' in position 0: character maps to so without the BOM CP-1252 is detected instead of Unicode. Nevertheless I was able to fix it but don't know how. Please test if it is now fixed for you as well. I also fixed now ar.po. thanks and regards Uwe
Re: [LyX/2.3.x] layouttranslations and uk.po: corrections from Yuri
Am 20.02.2018 um 00:06 schrieb Uwe Stöhr: is encoded in UTF-8 with BOM. So maybe the first character you see is the BOM: I first realized it thanks to your report. I found out that this is the default setting of my text editor when saving as UTF-8. For me on Windows the BOM is a good ideas because other programs get the information that the text/file is UTF-8 and not CP-1252-encoded. However, if the BOM makes problems, please tell me that I know and remove it from layouttranslations. - It seems that my replies to the lyx-devel list are no longer transferred. Moreover I can also not see Pavel's initial post there. (Maybe there is just an issue with my news server settings or firewall.) thanks and regards Uwe
Re: [LyX/2.3.x] layouttranslations and uk.po: corrections from Yuri
On Tue, Feb 20, 2018 at 04:38:03AM +, Scott Kostyshak wrote: > On Mon, Feb 19, 2018 at 11:18:57PM +, Pavel Sanda wrote: > > > $ make ../lib/layouttranslations > > LC_ALL=C ; export LC_ALL ; /usr/bin/python ./lyx_pot.py -b .. -o > > ../lib/layouttranslations -t layouttranslations ../lib/layouts/*.layout > > ../lib/layouts/*.inc ../lib/layouts/*.module ../lib/citeengines/*.citeengine > > Error: Unable to handle line: > > Traceback (most recent call last): > > File "./lyx_pot.py", line 687, in > > layouts_l10n(input_files, output, base, True) > > File "./lyx_pot.py", line 161, in layouts_l10n > > print(line) > > UnicodeEncodeError: 'ascii' codec can't encode character u'\ufeff' in > > position 0: ordinal not in range(128) > > make: *** [Makefile:785: ../lib/layouttranslations] Error 1 > > I see the same error. Uwe, will you have time to fix this issue soon? Thanks, Scott signature.asc Description: PGP signature
licensing statement
Dear LyX developers, I was asked to send a message to this list which states something like "I hereby license my contributions to LyX under the GNU Public License, version 2 or any later version." I hereby license my contributions to LyX under the GNU Public License, version 2 or any later version. Best, Alex Dunlap
Re: LFUN_INSET_END
Am Dienstag, den 20.02.2018, 16:21 +0100 schrieb Jean-Marc Lasgouttes: > Le 20/02/2018 à 15:53, Jürgen Spitzmüller a écrit : > > No, I see the same. i was mislead since that was the place where > > the > > next inset ended. > > > > But it is odd to consider the workarea an "inset" (at least this > > should > > be elaborated in the documentation). > > inset-select-all does the same, for example. Each inset is considered > as > a small document in itself. OK, but again, this is not obvious from the documentation. > > [1] command-sequence flex-insert Enquote ; char-backward ; inset- > > toggle > > ; char-forward ; inset-end ; char-forward > > > > (you see that the purpose of the last three lfuns is simply to jump > > over the inset) > > What you need is a function that leaves the inset by the end. I'd > say > that "escape" does that. Yes, escape works. Thanks. > Indeed inset-end is not predictable for scripting, like inset-select- > all > presumably. > > But to jump over the newly created inset, what about word-right in > this > case? Almost works, but this jumps after the blank following the inset rather than after the inset. Jürgen > > JMarc signature.asc Description: This is a digitally signed message part
Re: LFUN_INSET_END
Le 20/02/2018 à 15:53, Jürgen Spitzmüller a écrit : No, I see the same. i was mislead since that was the place where the next inset ended. But it is odd to consider the workarea an "inset" (at least this should be elaborated in the documentation). inset-select-all does the same, for example. Each inset is considered as a small document in itself. [1] command-sequence flex-insert Enquote ; char-backward ; inset-toggle ; char-forward ; inset-end ; char-forward (you see that the purpose of the last three lfuns is simply to jump over the inset) What you need is a function that leaves the inset by the end. I'd say that "escape" does that. Indeed inset-end is not predictable for scripting, like inset-select-all presumably. But to jump over the newly created inset, what about word-right in this case? JMarc
Re: LFUN_INSET_END
Am Dienstag, den 20.02.2018, 15:17 +0100 schrieb Jean-Marc Lasgouttes: > In my tests it goes at the end of the document, which is the end of > the > enclosing (main) inset. Do you see something different? No, I see the same. i was mislead since that was the place where the next inset ended. But it is odd to consider the workarea an "inset" (at least this should be elaborated in the documentation). Anyway, would it be hard to add an option that does not do that? I have inset-end in a command sequence [1] that inserts a (conglomerate-style) text inset, toggles it (i.e., the label) and moves the cursor behind it. Without a selection, the cursor jumps to the buffer end, which is pretty annoying. Jürgen [1] command-sequence flex-insert Enquote ; char-backward ; inset-toggle ; char-forward ; inset-end ; char-forward (you see that the purpose of the last three lfuns is simply to jump over the inset) > > JMarc > signature.asc Description: This is a digitally signed message part
Re: LFUN_INSET_END
Le 20/02/2018 à 15:11, Jürgen Spitzmüller a écrit : The description of this LFUN says: "Move the cursor to the end of the current inset if it is not already there, or at the end of the enclosing inset otherwise" However, if I have a text inset (not enclosed by another inset), and the cursor is at the end of it, the lfun will move the cursor after the next inset in the work area, whereas I'd expect it not to move at all according to the above description since (1) the cursor is already at the end of the current inset and (2) there is no enclosing inset. In my tests it goes at the end of the document, which is the end of the enclosing (main) inset. Do you see something different? JMarc
LFUN_INSET_END
The description of this LFUN says: "Move the cursor to the end of the current inset if it is not already there, or at the end of the enclosing inset otherwise" However, if I have a text inset (not enclosed by another inset), and the cursor is at the end of it, the lfun will move the cursor after the next inset in the work area, whereas I'd expect it not to move at all according to the above description since (1) the cursor is already at the end of the current inset and (2) there is no enclosing inset. Is this a bug or a documentation glitch? (if the latter, I'd prefer to have an option that makes the lfun act as described here) Jürgen signature.asc Description: This is a digitally signed message part
Re: Results of small poll - download speed of LyX installers & where we go from there
Joel Kulesza wrote: > What regions were those (I'm mostly curious)? US(NM) was one I know of, > validated through the result provided. Asia/South America > Before proceeding with this, have users been asked if a torrent is > appropriate for their needs? http://lyx.475766.n2.nabble.com/Why-the-download-of-Lyx-for-Windows-is-so-slow-td7580353.html > Or, perhaps I misunderstand and by connectivity problems you mean stability > of connection rather than speed (such that a torrent is the best answer)? These two are related, if you download at 10kb/s the chance it breaks after couple hours is quite high. Torrent is good because what has been already transmitted is not lost. > What I'm attempting to get at is: do we need another > download mechanism or do we need to refine/emphasize the message to > downloaders that alternatives exist and they may in in fact be faster than > the default? We added sentence to both web and announce file. I do not think we should do more when it comes to "emphasizing". > Along those lines, rather than spinning up a torrent, has > anyone investigated what it would take to get an auto-negotiating mirror > setup such that when someone downloads from the default site they are > automagically redirected to the fastest available mirror? Actually I spent some time to look on alternatives before proceeding with torrent way and it's painful. We could rely on 3rd parties, like sourceforge, but their reputation with adding adware to download pages in history is not exactly stellar and it would still need additional maintence work. To sum up, I reached my threshold of time I was willing to spend on the distributing issue and after dribbling with several variants this (kind of fake) torrent showed up as best; wrote the script and offered one-command solution without additional maintenance work. Whether maintainers want to use it or no it's up them... Pavel
Re: LyX version 2.3.0rc2 available
On Monday, 19 February 2018 11.42.57 WET Jean-Marc Lasgouttes wrote:
> Le 17/02/2018 à 14:02, José Abílio Matos a écrit :
> > How about the following patch?
>
> What happens if the format is not from a released version? In this case,
> we would like to keep the old naming IMO. I am not sure what your code
> intends to do in this case.
>
> JMarc
Something like what follows attached?
I have tested it with several cases and it works.
--
José Abílio
diff --git a/src/Buffer.cpp b/src/Buffer.cpp
index 7cabe6fce1..14ddbb4c10 100644
--- a/src/Buffer.cpp
+++ b/src/Buffer.cpp
@@ -1327,14 +1327,37 @@ Buffer::ReadStatus Buffer::convertLyXFormat(FileName const & fn,
FileName Buffer::getBackupName() const {
+ map const file_formats = {
+ {544, "23"},
+ {508, "22"},
+ {474, "21"},
+ {413, "20"},
+ {345, "16"},
+ {276, "15"},
+ {245, "14"},
+ {221, "13"},
+ {220, "12"},
+ {218, "1163"},
+ {217, "116"},
+ {216, "115"},
+ {215, "11"},
+ {210, "010"},
+ {200, "006"}
+ };
FileName const & fn = fileName();
string const fname = fn.onlyFileNameWithoutExt();
string const fext = fn.extension() + "~";
string const fpath = lyxrc.backupdir_path.empty() ?
fn.onlyPath().absFileName() :
lyxrc.backupdir_path;
- string const fform = convert(d->file_format);
- string const backname = fname + "-lyxformat-" + fform;
+ string backup_suffix;
+ // If file format is from a stable series use version instead of file format
+ auto const it = file_formats.find(d->file_format);
+ if (it != file_formats.end())
+ backup_suffix = "-lyx" + it->second;
+ else
+ backup_suffix = "-lyxformat-" + convert(d->file_format);
+ string const backname = fname + backup_suffix;
FileName backup(addName(fpath, addExtension(backname, fext)));
// limit recursion, just in case
Build failed in Jenkins: Build branch "master" » ubuntu-latest-qt5-cmake #746
https://ci.inria.fr/lyx/job/build-master-head/job/ubuntu-latest-qt5-cmake/746/-- [...truncated 185 lines...] Receiving objects: 26% (8430/32423), 29.11 MiB | 2.28 MiB/s Receiving objects: 27% (8755/32423), 29.11 MiB | 2.28 MiB/s Receiving objects: 28% (9079/32423), 31.55 MiB | 2.52 MiB/s Receiving objects: 29% (9403/32423), 31.55 MiB | 2.52 MiB/s Receiving objects: 29% (9451/32423), 32.81 MiB | 2.56 MiB/s Receiving objects: 30% (9727/32423), 33.51 MiB | 2.41 MiB/s Receiving objects: 31% (10052/32423), 33.51 MiB | 2.41 MiB/s Receiving objects: 32% (10376/32423), 34.82 MiB | 2.33 MiB/s Receiving objects: 32% (10425/32423), 34.82 MiB | 2.33 MiB/s Receiving objects: 33% (10700/32423), 35.17 MiB | 2.21 MiB/s Receiving objects: 34% (11024/32423), 35.17 MiB | 2.21 MiB/s Receiving objects: 35% (11349/32423), 35.17 MiB | 2.21 MiB/s Receiving objects: 35% (11542/32423), 36.33 MiB | 2.24 MiB/s Receiving objects: 35% (11577/32423), 37.78 MiB | 2.15 MiB/s Receiving objects: 36% (11673/32423), 39.24 MiB | 1.68 MiB/s Receiving objects: 37% (11997/32423), 39.24 MiB | 1.68 MiB/s Receiving objects: 38% (12321/32423), 39.24 MiB | 1.68 MiB/s Receiving objects: 39% (12645/32423), 39.24 MiB | 1.68 MiB/s Receiving objects: 40% (12970/32423), 39.24 MiB | 1.68 MiB/s Receiving objects: 40% (13241/32423), 39.24 MiB | 1.68 MiB/s Receiving objects: 41% (13294/32423), 39.24 MiB | 1.68 MiB/s Receiving objects: 42% (13618/32423), 41.28 MiB | 1.85 MiB/s Receiving objects: 42% (13697/32423), 42.00 MiB | 1.83 MiB/s Receiving objects: 43% (13942/32423), 42.80 MiB | 1.72 MiB/s Receiving objects: 44% (14267/32423), 42.80 MiB | 1.72 MiB/s Receiving objects: 45% (14591/32423), 42.80 MiB | 1.72 MiB/s Receiving objects: 46% (14915/32423), 42.80 MiB | 1.72 MiB/s Receiving objects: 47% (15239/32423), 42.80 MiB | 1.72 MiB/s Receiving objects: 47% (15383/32423), 44.06 MiB | 1.90 MiB/s Receiving objects: 47% (15401/32423), 44.99 MiB | 1.65 MiB/s Receiving objects: 47% (15429/32423), 45.98 MiB | 1.57 MiB/s Receiving objects: 48% (15564/32423), 46.43 MiB | 1.52 MiB/s Receiving objects: 48% (15690/32423), 46.95 MiB | 1.20 MiB/s Receiving objects: 49% (15888/32423), 46.95 MiB | 1.20 MiB/s Receiving objects: 50% (16212/32423), 46.95 MiB | 1.20 MiB/s Receiving objects: 51% (16536/32423), 46.95 MiB | 1.20 MiB/s Receiving objects: 52% (16860/32423), 46.95 MiB | 1.20 MiB/s Receiving objects: 52% (17110/32423), 50.25 MiB | 1.60 MiB/s Receiving objects: 53% (17185/32423), 50.25 MiB | 1.60 MiB/s Receiving objects: 53% (17398/32423), 52.15 MiB | 1.63 MiB/s Receiving objects: 54% (17509/32423), 52.15 MiB | 1.63 MiB/s Receiving objects: 55% (17833/32423), 52.89 MiB | 1.73 MiB/s Receiving objects: 56% (18157/32423), 52.89 MiB | 1.73 MiB/s Receiving objects: 57% (18482/32423), 52.89 MiB | 1.73 MiB/s Receiving objects: 57% (18743/32423), 52.89 MiB | 1.73 MiB/s Receiving objects: 58% (18806/32423), 56.15 MiB | 2.23 MiB/s Receiving objects: 58% (19048/32423), 56.15 MiB | 2.23 MiB/s Receiving objects: 59% (19130/32423), 56.91 MiB | 2.30 MiB/s Receiving objects: 59% (19337/32423), 57.87 MiB | 2.38 MiB/s Receiving objects: 59% (19375/32423), 58.90 MiB | 1.88 MiB/s Receiving objects: 60% (19454/32423), 59.56 MiB | 1.80 MiB/s Receiving objects: 61% (19779/32423), 59.56 MiB | 1.80 MiB/s Receiving objects: 62% (20103/32423), 59.56 MiB | 1.80 MiB/s Receiving objects: 63% (20427/32423), 60.94 MiB | 1.91 MiB/s Receiving objects: 63% (20659/32423), 60.94 MiB | 1.91 MiB/s Receiving objects: 63% (20686/32423), 62.87 MiB | 1.74 MiB/s Receiving objects: 64% (20751/32423), 63.45 MiB | 1.57 MiB/s Receiving objects: 65% (21075/32423), 63.45 MiB | 1.57 MiB/s Receiving objects: 66% (21400/32423), 63.45 MiB | 1.57 MiB/s Receiving objects: 67% (21724/32423), 63.45 MiB | 1.57 MiB/s Receiving objects: 68% (22048/32423), 63.45 MiB | 1.57 MiB/s Receiving objects: 69% (22372/32423), 63.45 MiB | 1.57 MiB/s Receiving objects: 70% (22697/32423), 63.45 MiB | 1.57 MiB/s Receiving objects: 71% (23021/32423), 63.45 MiB | 1.57 MiB/s Receiving objects: 72% (23345/32423), 63.45 MiB | 1.57 MiB/s Receiving objects: 72% (23601/32423), 65.38 MiB | 1.82 MiB/s Receiving objects: 73% (23669/32423), 66.99 MiB | 1.96 MiB/s Receiving objects: 74% (23994/32423), 66.99 MiB | 1.96 MiB/s Receiving objects: 75% (24318/32423), 66.99 MiB | 1.96 MiB/s Receiving objects: 76% (24642/32423), 69.00 MiB | 2.31 MiB/s Receiving objects: 77% (24966/32423), 69.00 MiB | 2.31 MiB/s Receiving objects: 78% (25290/32423), 69.00 MiB | 2.31 MiB/s Receiving objects: 79% (25615/32423), 69.00 MiB | 2.31 MiB/s Receiving objects: 79% (25771/32423), 69.00 MiB | 2.31 MiB/s Receiving objects: 80% (25939/32423), 69.00 M
Re: Results of small poll - download speed of LyX installers & where we go from there
Scott Kostyshak wrote: > On Mon, Feb 19, 2018 at 11:32:11PM +, Pavel Sanda wrote: > > > Richard(/Scott?) would it be doable for you to just add this one step > > on top of what you currently do while releasing? > > If I'm release manager at some point in the future, I would be happy to > learn more about it and take care of it. For 2.3.0 though, I would > prefer for you to do it, even if it is just a couple of simple > instructions. Yeah, I was thinking it might not be worth it giving your current load and single release left... Pavel
Re: Results of small poll - download speed of LyX installers & where we go from there
Richard Heck wrote:
> > From our side only one change in release process is needed -
> > creating torrent and putting on ftp next to other binaries (and .sig
> > file for security purpose). And perhaps one section in on Download
> > page, I'll take care of this one.
> >
> > Richard(/Scott?) would it be doable for you to just add this one step
> > on top of what you currently do while releasing?
>
> No problem for me, but I'd need instructions.
These lines would do after you receive the binary bundle and put it on
correct place of your local ftp tree:
FTP_PATH=your_local_dir_to_ftp_tree
PATH_TO_BUNDLE=path_from_top_of_ftp_tree
BUNDLE=name_of_bundle
cd $FTP_PATH
~/path_to_your_lyx_tree/development/tools/create_torrent
${PATH_TO_BUNDLE}/${BUNDLE}
mv ${BUNDLE}.torrent ${PATH_TO_BUNDLE}
cd $PATH_TO_BUNDLE
gpg -b --armor $BUNDLE #or whatever you use to sign the files, not
absolutely necessary though, ppl should check the final donloaded bundle anyway
rsync ... #upload to real ftp
Pavel
Re: Lost translators
Am Dienstag, den 20.02.2018, 00:41 -0500 schrieb Scott Kostyshak: > > Mark them as "inactive", as CTAN does for TeX package authors. > > To do this, we just append " (inactive)" to the name field, right? I'd say so, since the PO header does not have a specific category. https://www.gnu.org/software/trans-coord/manual/gnun/html_node/PO-Heade r.html Jürgen > > Scott signature.asc Description: This is a digitally signed message part
